An approach for developing indoor navigation systems for visually impaired people using Building Information Modeling

1. Introduction

According to the World Health Organization, the number of people with visual impairment was 285 million (4.25% of world population), of whom 246 million (86%) are with low vision and 39 million (14%) are blind [31]. The greatest limitations for impaired people in their daily lives depend mainly on environmental factors, such as navigation in large public buildings. Navigation is a complex task that includes [26]: 1) user localization; 2) path finding from start to target point; and 3) physical movement to target point, including obstacle avoidance. The feasible path may be composed of traversable elements that are located outside the buildings, inside the buildings, or both inside and outside. In many cases, finding the shortest, fastest, or safest path in large buildings implies the possibility that the path contain traversable elements outside of the buildings. Therefore, navigation within a city should combine outdoor and indoor navigation. As built environments grow in size and complexity, it is necessary to develop appropriate 3D city models [2,13,32,34]. These models should describe a 3D urban infrastructure, including the hierarchy of building elements and their horizontal and vertical connectivity [28]. When developing Indoor Navigation Systems (INS) for blind and visually impaired (BVI) people designers should take into account their preferences and abilities to navigate in buildings unfamiliar to them. Assistive technologies for people with disabilities should have an intuitive user interface and should be adaptive to the preferences of the users. The systems that are adaptive to changes in the environment are called context-aware systems [6]. Context-aware apps usually run on mobile devices and adaptively change their logic based on context data obtained from the surrounding environment. By interpreting the context, the navigation system is able to provide more precise path finding and more informative user guidance.

One of the main obstacles to the successful integration of BVI people into social, economic, and cultural life is the inability for them to safely and reliably move in unfamiliar spaces, whether outdoors or indoors. Problems typical of outdoor navigation are already partially solved. Yet indoor navigation systems, especially those designed for people with disabilities, have no real implementation. The main reason behind the disadvantages of current INS is the use of fragmentary approaches when designing such systems [23]. Our general objective is to design and implement a Building Information Model (BIM) that is focused on user navigation and that describes the hierarchy, geometry, and semantics of the building, users’ preferences, sensors deployed in the building, and connectivity between building elements.

The rest of the article is structured as follows. Section 2 provides critical analysis of the current INS for BVI people. Section 3 covers the basic disadvantages of BIMs found in current literature, which can be used for indoor navigation. The proposed approach for developing BIM-based INS is described in Section 4. Next, Section 5 discusses how to implement the proposed BIM. Section 6 presents a use case example. Finally, in Section 7, a conclusion is drawn and some future work is explained.

2. Current INS for BVI people

The majority of BIM-based indoor navigation systems [15,25] are designed for people without disabilities or for evacuation from buildings in an emergency. There is currently no BIM-based INS, consistent with the indoor navigation for people with disabilities. As mentioned in Section 1, the main reason for the disadvantages of current INS for BVI people is the use of fragmentary approaches to the design of such systems.

Building Information Modeling (BIM) technology has been receiving a growing amount of attention in the last few years [27,30]. The information integrated into BIM describes the whole lifecycle of the building. Countries whose governments will require the use of BIM in public construction projects include China, Canada and South Korea [19]. The adoption of the European Union Public Procurement Directive [4] means that all European member states may be encouraged to use BIM for publicly funded buildings by 2016.

Well-known BIMs that can be used for indoor navigation include the following:

BIM standards, such as CityGML and IFC, have been published to describe the 3D geometry and semantics of buildings, but they lack important features that are required for reliable indoor navigation. CtyGML has limited support for both fixed and movable obstacles. Neither standard supports user constraints. IndoorGML uses a graph model to represent building connectivity, but graph-based path finding usually uses only centroid of the spaces and connection information between spatial objects when calculating a feasible path. The actual geometry of nodes and obstacles within an indoor space should be taken into account to find the feasible path. Although BO-IDM describes spatial semantics, this model is not optimized for indoor navigation in large buildings with complex connectivity. INSM model can be used to specify the nodes and edges of the connectivity graph, but it is designed to support a coarse level of path finding according to the two-level path planning strategy. This model supports only two criteria (abstraction degree and number of openings) for the computation of a feasible path. The geometric data needed for computation of the physical path has not been part of this model, and INSM is not validated. Other BIMs, such as IESM, are designed to be able to meet the requirements for fast and reliable evacuation in an emergency. The evacuation of people, however, is only a special case of navigation in the buildings. This model does not take into account sensor and user semantics. The authors of IGNM reported some drawbacks of this model, for example: problems with non-convex objects; and for doors located in the corners of rooms, the path planning algorithm can produce serpentine routes.

People with disabilities cannot use the existing BIMs without modification for indoor navigation. For visually impaired people to reliably navigate in large public buildings that are unfamiliar to them, a BIM that combines in an object-oriented data model with all the necessary information is required.

OPEN IN VIEWER

Fig. 1.

Structure of the proposed data model (component parts and the relations between them).

The main modules (see Fig. 1) that should be part of an indoor navigation system are spatial model, localization module, user model, path finding algorithm with obstacle avoidance, evacuation planning, and sensor data acquisition, filtering, and reasoning. The proposed building model is designed to represent and combine human, technical, and infrastructure factors on which the movement of BVI people in unfamiliar public buildings depends.

User-centered design, based on the standard ISO 9241-210:2010 is used to guarantee the accessibility of the service. The final version of the system and user interface will be obtained from an adaptive iterative user-centered process (Fig. 1): 1) Specification – introducing a set of rules that are used to define characteristics of the system; 2) Implementation – using the current set of rules for the implementation of the next version of the system), 3) Evaluation – testing the last version of the system; and 4) Analysis – analyzing results obtained at the evaluation stage to check whether the set of rules must be adjusted.

The main objective of the proposed approach is to make combining data from functional modules of the navigation system into a data model possible.

This is achieved through a specially developed BIM. The majority of scientific publications related to BIM-based indoor navigation solve a specific problem that only affects one or more of these modules, such as evacuation [28] or path planning [33]. In practice, the functionality of each module depends on the design and functionality of the other modules. For example, an algorithm for path finding depends on the topology and geometry of the building and objects located in it, the module for localization of users and objects in the building, current status of the sensors deployed in the building, and user preferences.

4.1. Proposed BIM

The proposed BIM is not concerned with the architectural building components themselves. It focuses on the possible path elements (spaces), such as rooms and corridors, and the connectivity between these elements. Taking into account disadvantages of the current BIMs (see Section 3) following main requirements are defined:

Scalability (the possibility to model both small and large buildings).

Hierarchy (hierarchical description of the topology of buildings reduces memory usage and improves the time needed to find an optimal path).

Context-awareness. The system should be adaptive to the dynamic changes in the context by analyzing the data from sensors deployed in the building. The model should facilitate a description of the user preferences and opportunities for movement and should enable automatic recalculation of the path in dynamic environments (when the target point changes its location or a user deviates from the path).

On-the-fly path finding. A path finding algorithm can work when only a part of the building’s connectivity data is loaded into memory.

Easy and fast retrieval of the building’s topology from its data model.

Several levels of abstraction to model a building’s hierarchy are used. A hierarchical design is easily reusable, can represent large buildings with complex connectivity, usually scale well, and optimize memory and processor usage. It is assumed that buildings have wings. Each wing has one or several levels (stories). Rooms and corridors are part of the levels. Large rooms and corridors may be divided into sub-parts to represent indoor space more accurately.

Figure 2 shows relations between the classes that are responsible for the functionality of the proposed data model. The class details are as follows:

4.1.1. Building

The base class at the top of the spatial hierarchy is Building. Each building has properties such as name, type (university, school, hospital, etc.), number of wings, address, etc.

4.1.2. Wing

The second level of the spatial hierarchy is the Wing class, which contains one or several levels. Each wing of the building is assigned a name, identification code, a list of levels, connectivity with other wings, and a list of all possible escape exits (emergrncyExits). Using methods of this class it is possible to obtain the name of the wing, number of levels, a list of emergency exits, etc.

4.1.3. Level

Class Level comprises the third part of the spatial hierarchy. Each building level may contain path elements. A path element is an abstract building entity that can be part of the feasible path. To speed up path element searching, a hierarchy of path elements is used (attribute pathElementGroups), for example, rooms, doors, elevators, etc.

OPEN IN VIEWER

Fig. 2.

UML class diagram of proposed BIM (simplified).

4.1.4. PathElement

The building connectivity has been modeled based on path elements. In our model, a path element is an abstract component that represents any part of the path (node or link). For example, rooms, corridors, and elevators are nodes. Doors, openings, stairs, escalators, and horizontal ramps are links. The attribute nodes contain a list of all links through which the user can enter a node. The attribute links describe the nodes that a link connects. Through the value of these two attributes, a connectivity graph is generated, which is needed for the path finding algorithm.

4.1.5. Constraints

This class describes the restrictions that could be imposed on each path element. Restrictions may be spatial, temporal, or related to preferences and type of user disabilities. For example, some rooms may be accessible only to staff. Parts of rooms may be non-walkable areas. Access to the other rooms might be limited in time. In case of an emergency, access to building elements such as elevators and corridors impacted by the fire or smoke should be blocked. Certain doors might provide access in one direction only (emergency exits) or forbid access to a specific group of users (areas with a specific level of security).

4.1.6. Link

A Link describes the connectivity between nodes. The links are divided into horizontal and vertical links. For example, with the attributes of the class Link, one can identify which nodes the link connects and if it can be used for evacuation.

4.1.7. Door and Window

The Door class represents all type of doors. This class describes the type of door (real or virtual, unidirectional or bidirectional, external or not), opening direction, status, position of the handle, etc. The class Window has similar attributes to the Door class. If the window links the building with the outdoors, it may be used for user evacuation if all other possible paths to the outdoors are blocked. For example, in [28] windows that are less than one meter from either the ground or roof could be used as emergency exits.

4.1.8. Node

Node is a class that describes the spaces in the building through which the user can pass if he or she has the appropriate rights. Nodes are divided into horizontal (class HorizontalNode) and vertical (class VerticalNode) nodes. Horizontal nodes are related to the horizontal movement of users, for example, rooms and corridors. The elevators are a special type of node and can be used to connect many building levels. Although the elevator is a part of the vertical connectivity of the building, in our model it is not a link element because an elevator has doors and some users and objects may be located in it. The methods of this class enable one to obtain a list of the objects located in the node, to search a specific object, etc.

4.1.9. Room and Corridor

These classes represent base horizontal nodes. It is possible to deconstruct building spaces such as long corridors and large rooms into smaller parts (class Part) to represent indoor spaces more accurately. The long corridors are automatically divided into smaller parts, depending on the corridor intersections and the location of the fire and gas sensors. This is necessary because the path finding algorithm returns paths along the walls of the corridors, and it is possible to obtain a long detour when a corridor has many intersections. Furthermore, in case of fire and smoke, it is possible for only certain parts of a corridor to be blocked. Specific places in large rooms can be described through the Zone class, for example, a reception desk in the lobby of the hotel.

4.1.10. Object

This class describes all physical objects located in the building. The objects are classified as: 1) Landmarks (objects that help a person to stay oriented and maintain a sense of being on route), 2) Obstacles (obstructions along the path), and 3) Hazards (obstructions that are hard to detect). The main attributes that describe object characteristics are as follows: name and identification number, node to which the object belongs, list of sensors associated with the object, is an object fixed or movable, etc.

4.1.11. Sensor

The Sensor class represents any sensor located in the building environment. Class SensorInfo is used to describe sensor characteristics such as id, type, location, and class SensorContext to represent context obtained from raw sensor data. To receive data from the sensors, a program class implements the interface SensorListener. The callback functions newContext and newEvent must be declared in the class that implements this interface.

4.1.12. People

The People class allows access to the user model. People located in the building are divided into Staff and Visitors. The attributes provide semantic information, such as user demographics (name and gender), impairment type, navigational preferences, user interface preferences, movement history, etc.

4.1.13. Other classes

The Boundary class is used for representing the flooring and walls of all nodes and links. The Wall class represents the vertical subdivision between rooms and corridors.

4.2. Geometric model

The geometric model allows for the precise localization of objects and description of paths. A simplified geometric model is used (see Fig. 3) in order to retrieve the necessary geometric data in real time. The basic geometric objects used are point, line segment, polyline, and 3D polygon. In order to represent the geometry of path elements and objects Euclidean or WSG 84 spaces are used. Polygons are used to represent the building’s and objects’ geometry. Administrative boundaries and areas-of-interest are modeled with 2D polygons.

OPEN IN VIEWER

Fig. 3.

Geometry part of proposed BIM.

The building footprint, wings, and objects are modeled with 3D polygons (class POLYGONZ). 3D-polygon features store z-coordinates embedded inside their feature geometry. The class CIRCLE describes objects with a circular cross-section. Each circle is actually a polygon, whose points are automatically determined depending on the radius of the circle. Class SOLID represents whole building, wings, floors, nodes, and objects. At this time SOLID class attributes represents the type, volume, and area of the rooms and corridors. Class SURFACE represents the boundary of nodes, links, and objects.

Blind people prefer to follow paths along the corridor and room walls using white cane. Polygon buffering is used to represent the path close to walls. For rooms and corridors, an inner buffer is calculated. To detour objects located in the building, the outer buffer is calculated.

5. BIM implementation

This section discusses how to implement the proposed BIM as a repository of building data. Each BIM module is specified by an XML schema definition file and is defined within an individual and globally unique XML target namespace. Cloud-located service for indoor navigation is developed to validate the proposed building data model (see Fig. 4). Google App Engine (GAE) is used to deploy the service.

OPEN IN VIEWER

Fig. 4.

Service-oriented INS architecture.

To access the service responsible for acquiring and managing data from the sensors, REST queries are used. RESTful protocol provides an object level (sensors and actuators) interface to the corresponding BIM objects. The names of these objects are identified directly by URIs. When a sensor changes its status, a REST query that contains information about this change is sent to the service. The sensors can be programmed to send data when: 1) The value of a parameter has changed with the specified absolute value or a percentage; 2) The value of a parameter is above or below a specified threshold level; 3) An event from a smart sensor is detected. Mobile clients use AJAX in order to enable a fast asynchronous information transfer from clients to the corresponding service

5.2. Data-access model

A layered data access approach is implemented to guarantee scalable design of the data access model (see Fig. 5). Each location-based user request is converted to a SQL-style query.

OPEN IN VIEWER

Fig. 5.

Data access model.

The specially designed SQL layer (L1) transforms SQL queries to a request to the second layer L2. The query cache uses the SELECT clause as a key and result set as a value. If a current SELECT query is located in the cache, SQL parsing and execution is not required. The second layer (L2) performs basic CRUD (create, read, update, delete) functions. The service layer is an object-oriented data access model which contains a part or all of the building’s data.

This architecture is optimized to speed up read operations. When the second layer cannot return an answer because required data are missing in memory, these data are fetched from protocol buffers or datastore (L3). Compared to XML data description, Google protocol buffers are up to 10 times smaller and up to 100 times faster.

5.4. Path-finding algorithm

The path finding algorithm should find the best suitable path for a particular user from start to target point. Specially designed path planning algorithm that finds an optimal path in three steps is used: First, K-shortest paths to the target point are obtained; Second, fine-grained paths using a geometric model are calculated; and finally, an optimal path with the highest total rank using a multi-objective optimization technique is returned. Based on an interview, it is decided that the selection of the optimal path will depend on six parameters: 1) Length of the path (min), 2) Number of objects that are obstacles or hazards for BVI users (min), 3) Number of objects that are landmarks and cues for BVI users (max), 4) Number of doors through which the user should pass (min), 5) Number of changes in direction of movement (min), and 6) Number of intersection points in corridors (min). The initial values of the importance of each criterion are obtained using the ranks correlation theory.

OPEN IN VIEWER

Fig. 6.

Path finding in a 3D building simulated environment.

The algorithm takes into account the current user position. It is invariant to the number of obstacles, their shape, orientation, and position in the room and works with cyclic or acyclic, directed or undirected graphs. Path-finding algorithm performance was tested in several simulated 2D and 3D environments. Figure 6 shows the 3D topology of a simulated building, which has three wings (left, middle, and right), and each wing has five floors (level 0–level 4). To evaluate the performance of the path finding algorithm in a 3D building environment, three groups of test scenarios are used:

Inside-to-inside path finding (for example, from “room 1” to “room 2”).

Inside-to-outside path finding (for example, from “room 2” to “outside”).

Outside-to-inside path finding (for example, from “outside” to “level 0, left wing”).

Table 4 shows the performance of the path finding algorithm compared to Yen’s algorithm for both test scenarios.

OPEN IN VIEWER

Table 4

Runtime test in 3D building environment

Test scenario	Yen’s KSP algorithm		Proposed algorithm
	Number of found paths	Runtime, ms	Number of found paths	Runtime, ms
1	8 1)	46.8	8	6.48
2	10 1)	16.2	10	2.28
3	243	438	243	35.5

¹⁾

The adjacency matrix should be corrected, in order to prevent obtaining extra paths that include node “outdoors”.

Both algorithms correctly find the maximum number of feasible paths, but the proposed algorithm is from 7 to 12 times faster. For example, for a complete, undirected graph with 10 nodes (109,601 possible paths), our algorithm is 337 times faster compared to Yen’s path finding algorithm.

6. Use case example

At this stage, the services that implement BIM-based navigation system are deployed on GAE. An HTML5-based service (Building Builder) is used to allows 2D/3D modeling and visualization of the building and its elements using WebGL The spatial information can be generated using primitive graphics or IFC files. The information needed to build BIM can be exported in XML format (see Fig. 7).

At this moment, due to the lack of large public smart building, the functionality of the services was tested through XML scripts that describe the changes in context data over time (status of sensors, objects, and clients). These scripts are generated by an HTML5-based service named Building Simulator. Users of the service can filter out information that they wish to use. For this purpose, the building information is divided into layers: topology; sensors and actuators; objects; staff and visitors; constraints; raw context; and events. The service allows users to change the topology; add and remove objects, sensors and actuators; generate a certain number of visitors and staff members with a specified or random location; set access restrictions (spatial, temporal, or related to type of user preferences and disabilities); and simulate a change of context.

OPEN IN VIEWER

Fig. 7.

XML script – building topology.

Each client of the service receives an NFC identification card. The card is used to: a) automatically install the app on the client side at first touch of the mobile phone to the card; b) automatically start the application if it is already installed; c) authorize the client to access the service. To ensure the security of the client, two-factor authorization and a one-time URI for access to the resources of the service have been implemented.

The user reaches the desired building using a GPS-based outdoor navigation system. To inform clients that they have reached the building, the system uses iBeacons. When a client approaches one of the entrances of the building (15–20 m), the client receives a push notification with the name and designation of the building. The client can then obtain further information about the topology of the building including information about floors, entrances, exits, and whether the building is accessible to people with disabilities.

The system provides prompts through a synthesized voice (TTS) client to choose a destination point. This can be a floor number, the name of the room, an emergency exit, a staff member or visitor name(s), or another relevant bit of unique information. The description of large public buildings using BIM involves working with large datasets. Therefore it needs a flexible, fast and intelligent way to retrieve data from BIM. One way of achieving this is to allow the use of natural voice-based requests. A similar approach is used by voice assistants such as Microsoft Cortana, Apple Siri, and Google Now. The proposed system uses natural voice-based queries to retrieve data from BIM, for example: “information desk”, “orthopedic emergency room”, or “Dr. Smith.” The system uses a speech recognition engine with distributed architecture. The frontend stage (mobile terminal side) includes microphone capture; start and stop point extraction; and noise reduction if necessary. Backend stage of the service has mashup architecture. The goal is superior speech recognition probability and reliability of the service. For the implementation of Automatic Speech Recognition (ASR) at this stage, the system uses two cloud-based services that are available through the following API: Google Speech API and Bing Speech API. Both services require registration to obtain an access key. The Bing Speech API supports chunked transfer-encoding for live transcription scenarios. Both APIs use POST requests to send voice data (Google Speech API requires FLAC format with a sampling rate 16 kHz, while Bing Speech API requires WAV format at an 8 or 16 kHz sampling rate). The result is provided in JSON format and contains status, recognized text, and confidence value.

OPEN IN VIEWER

Fig. 8.

Simulated 2D environment.

Let’s assume that the client is a woman who is looking for the nearest women’s room. The client is located in one of the rooms of the apartment (see Fig. 8), which has 12 nodes (rooms) and 18 links (doors and open spaces). Google Speech API for sentence “Where is the nearest women’s room?” returns the following result:

The most likely result (confidence 0.82209402) according to this service is “where is the nearest women’s room.” Microsoft API returns the same result (confidence 0.9442599) and provides additional information such as the lexical interpretation, tokens, and pronunciation. The average response time (4G mobile network) is 1550 ms for Google Speech API and 900 ms for Bing Speech API.

After the service receives the query as a text, it starts a linguistic analysis in the following sequence: a) sentence separation (breaking text into sentences, finding the end-of-sentence markers); b) tokenization (breaking the character sequence into words); c) tagging (identifying the category of each word – noun, verb, adjective, etc.); d) semantic analysis (finding relations between keywords from the user query and the names of objects and their properties); e) mapping (finding keywords, replacing them with synonyms if necessary, and mapping the final keywords to the names of BIM objects or the names of their properties).

For the realization of the rest part of natural language processing, our system currently uses only the Microsoft Linguistic Analysis API. This cloud-based service uses POST requests to send the result obtained from ASR. The result is provided in JSON format and contains information about the phrase types. Average response time is 250 ms. If the client’s voice query is “Where is the nearest women’s room?”, the following result from linguistic analysis is obtained:

where:

In some cases, the system may require the client to confirm or specify a query. This is necessary if the probability of correct identification is below a predefined level or if the query suggests an ambiguous response, for example: “Please confirm that you are looking for an orthopedic room”, “Three doctors named Smith (full names and their specialty follows) work in this building. Which of them are you looking for?”

In our case, it is clear that this is a query for a place (where is). The client is looking for a “women’s room.” The dictionary of synonyms provides the keyword “toilet”, which corresponds to the term “women’s room.” There is an additional requirement: nearest to the client room that is accessible to women. The query that is generated to retrieve information about the objects that match this query is:

Once the start and destination point are known, the algorithm for route planning is started (start point coincides with the current location of the client).

First, the algorithm retrieves information from BIM about the connectivity of the elements of the building that are within the scope of the query (node, apartment, floor, wing, or building). Using these data, the algorithm finds K feasible paths (macroscopic stage). By default, K = 4 . Second, using data from geometry part of the BIM, the microscopic stage of the algorithm calculates an optimal path for a certain client. It considers the preferences of the client, which are derived from his or her user model, and the status of the sensors deployed in the building. The system uses multi-parameter optimization to calculate an optimal path. The calculated best feasible path is described in XML format as a sequence of waypoints. In our case, the system returns all objects of class toilet that fall within specified scope “Apartment-002”: toilet-1 (node 4) and toilet-2 (node 14). From Constrains part of BIM it is clear that both toilets are accessible to visitors. The system checks whether the user has access to the found toilets. This information is obtained from the user’s profile, which is part of the proposed BIM. The number of all possible paths from the current user’s position to each one of the toilets is six. The macroscopic part of the path finding algorithm allows finding multiple similar target points in a single search. The algorithm returns all 12 possible paths to the target point (toilet), arranged according to the number of links through which the user should pass:

To find an optimal path for a particular user, the values of objective function F w for the first four best feasible paths should be calculated (see Table 5). The weights of the used criteria for a particular user (obtained from user’s model) are W = [ 0.2640 , 0.2360 , 0.2267 , 0.1507 , 0.0853 , 0.0373 ] . The optimal path is the one with the number 1. Because the client is looking for the nearest women’s room, the system provides information about the path with the shortest length. In the present case, this path is also optimal for the client feasible path. Context-aware path finding takes maximum 65 ms. Location-based query average response time is 1850 ms.

This manuscript identifies the most common solutions for indoor navigation for BVI people. It can be concluded that the existing approaches concerning indoor navigation have fragmentary designs and provide only partial solutions. This study presents an approach for developing INS for BVI people. This approach uses a specially designed BIM that combines in one data model all information necessary for indoor navigation of large public buildings. Table 6 shows how the proposed approach meets the requirements (described in Section 2) that are not implemented or partially implemented in existing INS.

The navigation of visually impaired people in large public buildings is a complex task. So far, no navigation system provides the necessary reliability for the navigation of blind people, regardless of design and architecture. The use of solutions that are independent of the infrastructure of the building are based on the recognition of scenes/images and inertial navigation. Despite the very good results in the field of pattern recognition using the deep learning of neural networks, navigation systems using this approach are not applicable to people with disabilities for a few reasons. These systems is highly dependent on the illumination in the building and becomes inoperable with a lack of power supply, or with fire or smoke in the building; and the probability of correct recognition in real conditions is not sufficient for reliable navigation for people with disabilities.

The proposed approach for creating indoor navigation systems, which is based on bringing together all the information necessary for reliable navigation in a single data model, involves the use of smart buildings with specific infrastructure (sensors and actuators). The requirements for the use of BIM for the design and construction of buildings worldwide, as well as trends for construction of smart buildings, suggests that the proposed approach would be easy to implement in the near future. This approach is based on technologies that are now beginning to show their potential, for example: Internet of Things (IoT), energy harvesting sensors, ultra low power microcontrollers, personalized apps, and cloud-based services. The technologies required for the operation of the proposed type navigation systems will be generally available in the near future.

Due to the lack of buildings with the necessary infrastructure (sensors and actuators) at this time, tests were conducted with simulated 2D/3D building environments. The results of these initial tests support the use of BIM for enabling indoor path finding in large public buildings. These results have demonstrated that information extracted from BIM would support the conceptual requirements of indoor navigation.

It is expected that the proposed BIM can give a new approach to solving existing problems in the area of indoor navigation for BVI people. Future work will focus on implementing the proposed approach using real smart building environments and on testing the usability of our BIM-oriented indoor navigation system.