A novel context-aware augmented reality framework for maintenance systems

1. Introduction

Efficient Operation and Maintenance (O&M) guarantees reliability, safety, and energy saving of equipment. O&M includes actions required to upkeep equipment and facilities and helps to lengthen the equipment lifecycle [14,21]. The complex structure of equipment means that technicians face difficulties to conduct maintenance activities [26] and that access to technical paper-based manuals is required especially when these activities are performed infrequently [18].

Computing technologies have enabled developers to support maintenance activities faster, more reliable and more intuitive. As a consequence, traditional paper-based manuals are on the verge of extinction [8]. AR technology, which has been used in various domains including maintenance [22], is technology which can be employed to assist users completing steps of a maintenance task by overlaying virtual objects on a real-time equipment scene and providing human-machine interaction as well [4,22]. AR technology improves a user’s perception of maintenance activities by superimposing multimedia alerts and providing bi-directional visual interaction between the user and the system [14]. However, context-awareness, which is an integral part of improving systems usability, needs to be employed in order to adapt the system’s behavior and output based on a user’s context [26].

Context is defined as a set of states and settings in the environment that determines an application’s behavior or in which an application event occurs that is of interest to the user [3]. Context can be divided into three groups, namely, computing context (network bandwidth, communication cost, etc.), user context (user profile, people nearby, etc.) and physical context (light, noise level, etc.) [16]. The following examples of context will make it clear. A user location can be used to alert on future preventive jobs about equipment nearby to the user. As another example, a user’s expertise level, defined as user context, affects details of the information to be shown. A user with a high expertise level needs less details to perform a task, but a novice user requires more details to help him finish the job. Suppose a user which runs the system on his tablet device. If the battery level of his device goes below a certain value (e.g. 25%) or the CPU usage of his device goes higher than a threshold (e.g. 85%), then the system should avoid overlaying 3D models that consume more battery and need more processing resources. A textual overlay should be used instead.

In addition, one should keep in mind that the goal of providing context-awareness within AR-based maintenance systems is to improve efficiency and reduce the time, cost and effort required to complete maintenance tasks. However, the achievement of this goal should not affect the performance of the proposed systems in case of run-time and resources. The aforementioned systems need to be able to run as fast as possible even on devices with limited computational resources, and they should not take an intolerable amount of time to provide output for the final user.

This paper presents an optimized context-aware AR-based framework to assist technicians conducting maintenance tasks. The proposed framework makes use of collected raw context data and performs reasoning on them to obtain new inferred data and to provide adaptive behavior using an ontology. On the other hand, the responsibility of selecting the collection of information instances to assist the technician for each step of ongoing maintenance routine is granted to a behavior network. The latter inconsiderably improves the performance of the system instead of running time-consuming SWRL rules.

The rest of this paper is organized as follows. Section 2 gives a review of context-aware systems in various domains. Section 3 shows the architecture of the proposed framework in this paper. An experiment of the proposed framework is presented in Section 4. Results of employing the proposed framework are provided in Section 5. Section 6 summarizes the paper and introduces future works.

2. Related work

Conducting activities, such as scheduling, periodical controls, performing preventive and predictive procedures, ensures that property and equipment achieve their intended goals. Preventing breakdowns, increasing efficiency, reliability and safety are the main purposes of operation and maintenance activities [8,21].

AR technology can be utilized to train complicated procedures and provide maintenance instructions as well as visual interactions to onsite technicians and it has proved to be useful in a maintenance context [26].

Wang et al. developed a framework for an AR-based system to conduct complicated maintenance tasks cooperatively and efficiently through a local network infrastructure between technicians and remote experts [23]. Schwald et al. proposed an AR system to aid technicians in maintaining equipment in an operational condition as well as instructing them how to use facilities [18]. AROMA-FF encompasses an AR-based interface in order to superimpose 3D assistive models and a maintenance information model including equipment settings, sub-systems, components, actors, maintenance history, sensor-based live data stream and geometric representations [8].

To reach the goal of improving the usability of AR maintenance systems, there is a need to utilize context-aware computing [25] in order to discover contextual information and use them to provide more practical information to the users [3]. As a result, virtual information will be changed according to various context [26] and the intelligent behavior in a smart environment will be improved [15].

Gouin-Vallerand et al. employ different types of contextual information including user profiles, device profiles, etc. and propose a context-aware service provision to be used in smart environments [5]. The CoMotion project at MIT exploits GPS-based user location as a context parameter and plays back a recorded message automatically as soon as a recipient arrives at the desired location [11]. CyberGuide, an information provider service, takes advantage of both user location and orientation to provide information such as directions, background information, places of interest and people comments for the tourists [1,9]. A notepad application is developed by Schmidt et al. for a PDA device to adapt the font size and backlight based on the user’s context, such as moving state and light level. In another scenario, a mobile phone profile is changed depending on the current phone state [17]. Oh et al. suggest CAMAR, which is a mixture of mobile AR and context-awareness. CAMAR makes use of unified user context information and allows users to view and tailor augmented information to share them with other end users [13]. Mileo et al. present a context model that makes use of information from pervasive sensors placed in the environment and patient explanatory feedback as well to interpret complex collected data and reason about available knowledge using logic programming language in order to support patient well-being [12]. Byun et al. employed context history beside user modeling and machine learning algorithms to provide adaptation. The proposed system collects and learns user preferences about the office window state in different room conditions. Afterwards, the user desired window state will be induced based on the gathered data, i.e. user behavior [2].

Context-awareness is not widely used due to the lack of effective infrastructure to support context-aware applications [15]. Ontology has been widely used for context modeling to define concepts in a specific domain and relations between concepts [19]. Ontology provides benefits such as knowledge sharing, logic-based reasoning and inference, and knowledge reuse [24]. Entities and their relations are introduced in the form of classes, subclasses and properties in ontologies. Each class can have several subclasses, individuals and properties. Properties are divided into two types, object and data properties. Object properties define a relation from an individual to another individual. Data properties define a relation from an individual to a data value such as a String, Boolean, Date, Time, etc. [7].

A formal general reusable ontology-based context model, including a default vocabulary and extendable structure, is provided by Hoque et al. to support ontology-based reasoning and rule-based reasoning in a smart home environment [6]. CONON takes care of context modeling and ontology reasoning in addition to user defined reasoning in a pervasive computing environment. It defines a basic context ontology consist of general concepts and the ability to extend ontology for a specific domain hierarchically [24]. A combination of first order probabilistic logic and web ontology language (OWL) is implemented as an agent-based middleware by Qin et al. to gain contextual information, knowledge demonstration, usage and sharing in context-aware applications [15].

Ong et al. present a novel ontology-based context-aware AR maintenance system to support the provision of context related information to the technicians. In addition, the system provides a real-time collaborative interface for technicians to ask for help from remote experts or vendors as well [14]. Another context-aware maintenance application based on ontology equipped with AR technology with the ability to run on a tablet PC is introduced by Flatt et al. This software superimposes maintenance information beside live operational data as virtual information on screen and allows users to attach sticky notes to the equipment components enriched with position information and makes them recognizable later even in different camera positions [4]. Zhu et al. introduced an Authorable Context-aware Augmented Reality System (ACARS) using ontology as a context modeler to support technicians in maintenance jobs and enable them to interact with AR contents. As a result, they can create new augmented information themselves or revise formerly created information [26]. Authoring for Context-Aware AR (ACAAR) is another authoring tool to create augmented context-aware information in maintenance AR applications with little programming skills by employing ontology. ACAAR allows the technicians to correlate virtual information with different contexts [25].

Behavior Network takes responsibility for the problem of action selection in an agent-based environment. Each agent faces a collection of competence modules. Changes in the activation level of each module will lead to its activation. The agent will select the modules with the highest activation level greater than desired threshold [10].

Song and Cho present a context-adaptive user interface for the simplification of using different control devices containing different functions on each device in a home environment. The proposed system takes advantage of a Bayesian network to predict the desired devices in the user current situation and then employs a behavior network to select the required functions at each step hierarchically [20].

The literature review shows that many context-aware systems have been designed and implemented in various domains. However, context-awareness has been disregarded in the maintenance domain and there is not much research done in this field. Thus, most of the maintenance AR applications have been deprived of promising benefits of context-awareness, such as improved usability. But while improving usability due to context-awareness, performance of the system needs to be considered. Conventional ontology-based context-aware maintenance systems are in charge of defining what needs be shown in each step of a maintenance task using SWRL rules. These rules are time-consuming and as they grow the performance of the system decreases. In an industrial environment with 10,000 facilities, where each facility has more or less maintenance tasks with 10 steps or more to complete the job, applying rules and inferring the relevant output of each step by using a reasoner will be time-consuming and it is not bearable for the user to wait minutes for the system to start working.

In this paper, we propose a context-aware framework as a base for an AR maintenance application. The proposed system employs an OWL ontology for context-awareness, and uses behavior network to select actions to be conducted at each step as a supplement to improve run-time speed. Thus, the ability of running applications on devices with limited processing resources will be provided and the system starts working in a reasonably acceptable time.

3. System overview

This section describes the process of development of a context-aware AR maintenance system. As stated before, AR can superimpose maintenance information instances on real equipment and describe a virtual equivalent of a specific type of information, such as paper-based manuals, usage instructions, repair procedures, etc. to the users.

3.2. AR-based maintenance system

Different types of information instances described in 3.1 can be presented using AR technology. For this to happen there should exist three phases in each AR system, as shown in Fig. 1, namely Identification (P1), Retrieval (P2) and Visualization (P3).

OPEN IN VIEWER

Fig. 1.

Phases of AR systems.

Identification (P1) is responsible for recognizing equipment in the environment automatically by means of an equipment’s natural features or visual markers attached to the equipment by employing computer vision-based object recognition algorithms, RFID devices, GPS-based location and orientation, etc. or manual input of a user into the system specifying the equipment. The proposed system in this research uses natural features to detect and track equipment in the environment. To do so, the system needs to be trained in advance. Therefore, an image of the equipment should be fed to the system for the sake of feature extraction. Finishing this procedure will create a dictionary containing natural features of the equipment, which can be used for further detection and tracking purposes. Figure 2 shows an original image taken from an equipment and Fig. 3 shows the extracted features of this equipment.

OPEN IN VIEWER

Fig. 2.

Original equipment image.

OPEN IN VIEWER

Fig. 3.

Equipment image feature set.

The second phase in AR-based systems is Retrieval phase (P2) which is in charge of obtaining maintenance related information or live data through various databases and pass them to the next phase.

Visualization (P3), the last phase, integrates retrieved information and superimposes them on real equipment scenes obtained through live video streams. AR technology fulfills the requirements to implement these phases.

3.3. Adaptation scheme

The important fact is that showing static virtual information to the user is not satisfactory. So output information needs to be selected based on a user’s context such as expertise level, skill name, interested color, location, etc. in Retrieval phase (P2) which context-awareness seeks to fulfill in AR-based maintenance systems. Therefore an adaptation engine is considered within Retrieval phase (P2) as shown in Fig. 4. This scheme is the basis for the provision of relevant information to the users in the terms of content and presentation.

OPEN IN VIEWER

Fig. 4.

Adaptation engine.

The Adaptation Engine as shown in Fig. 4 is the heart of Retrieval phase (P2) and is divided into two subsections referred to as the Selector and Renderer. The Selector receives real time context, predefined logical rules and instances from ontology as input. After applying logical rules on the received context, the Selector chooses which combination of virtual information needs to be retrieved from the maintenance database to be displayed on the scene using a behavior network. This combination is next passed to the Renderer which applies rendering properties such as color, transparency, etc. considering the rules defined in the ontology by system developers. Output generated by this module will be based on what needs to be displayed on the screen.

3.4. System architecture

The proposed system consists of five different modules, namely, the System Core, Context Collector, Behavior Network, Reasoner, Visualization and databases to provide context-aware information instances to the final user, as shown in Fig. 5. The System Core module is called initially whenever the system starts working, and it establishes the links between different modules. The Context Collector is responsible for providing real time context to the System Core. The Behavior Network prepares a combination of instructions to be displayed from the maintenance database based on the rules step, individuals and properties defined in the system ontology and return them back to the System Core module. Applying the rules defined in ontology over individuals and sending back the results to the Behavior Network is the Reasoner’s duty. The Visualization module receives the combination of output information from the System Core and presents them on the screen. Embedded modules interact with each other as well as some other external libraries. A description of each module is provided as follows.

OPEN IN VIEWER

Fig. 5.

System architecture.

3.4.1. System core module

As Fig. 5 illustrates, the System Core module is the start point of the system and will be called initially whenever the system starts. For the system to function, there is a need for a controller to provide a link between the different modules. This controller triggers other modules whenever needed, and retrieves results after process completion in the fired module. The System Core plays the role of a controller in the proposed system.

First and foremost, the System Core calls for the Context Collector to obtain real time context. After collection of these raw context data, they are passed to the Behavior Network module via the System Core to choose output information accordingly. Acquired combination of information will be passed to the Visualization module in order to be displayed on the screen.

3.4.2. Context collector module

This module has a main class referred to as Context Provider which is called by System Core module. This class asks for real time context which can be obtained in two methods.

The first method is by reading live sensor data, such as the time of day, current date, battery level, CPU usage level and etc. automatically. The second method is gathering information through manual user input such as person expertise level, person preferred color and etc. The Context Provider class transmits these raw context collected data to the System Core for further processing.

3.4.3. Reasoner module

In order to describe the maintenance environment, context modeling is needed which defines entities and relations between them. Context modeling plays an important role in the process of implementing context-aware applications in order to provide information according to the status of people, equipment, activity and etc. Following section provides a description of the context modeling used in our proposed system.

OPEN IN VIEWER

Fig. 6.

CAMON ontology.

Ontology This research adopts the CONON ontology proposed by Wang et al. as the base ontology [24]. Some customization and extension are being done upon it to model a maintenance context in order to provide a common definition for certain maintenance concepts and their inter-relations. The proposed ontology in this research is named CAMON as an abbreviation for Context Aware Maintenance ONtology. As illustrated in Fig. 6, CAMON consists of five base classes named Activity, CompEntity, Information-Instance, Location and Person. Activity subclasses represent different maintenance activities described in Section 3.1. CompEntity includes CompDevice, Equipment and SensorDevice as subclasses. CompDevice represents a user’s computational devices, such as mobile, tablet, etc. which are used to run the system during a maintenance activity. Equipment represents facilities that the technician will perform an activity on. SensorDevice holds AR markers placed in the environment. Location is divided to IndoorSpace and OutdoorSpace. Person represents everybody that is involved in a maintenance activity. BDM_Engineer are those engineers who carry out a corrective maintenance activity. PM_Engineer represents those who perform a preventive activity routine on an equipment. Manager is a delegate of persons who are involved in monitoring activities and Operator represents persons who have decided to run an operation on an equipment. InformationInstance holds the related rule name of each activity to be displayed over the scene.

Based on the maintenance environment, these classes can be changed or extended and individuals may be inserted into the ontology. For example, the definition of ChangeFilter as an individual of class Activity is illustrated in Fig. 7. This activity is conducted on an equipment named CarEngine, uses information named ChangeFilter_Rule as information instance, failure reason is stated as DirtyAirFilter and current status of activity is at Step 1.

As another example, an individual named John is created as an individual of Person class as illustrated in Fig. 8. John is engaged in a ChangeFilter activity. He is in charge of an iPhone6 device. His expertise level is defined as Low, the preferred color is saved as Red, and the skill name is stated as Mechanic.

OPEN IN VIEWER

Fig. 7.

Create an individual of Activity class.

OPEN IN VIEWER

Fig. 8.

Define an individual of Person class.

Logical rule definition Logical rules which describe the environment in detail will be defined using SWRL rules. Any SWRL rule consists of two parts named Body and Head. Body contains a set of preconditions and Head contains a set of actions which will be taken into account whenever the Body preconditions are satisfied completely. An example of SWRL rule is presented in Fig. 9. In this example, if atoms A(?x) and B(?x) are satisfied, action C(?x) will be taken and the result will be true. A, B and C can be classes, object properties or data properties and x introduces a variable in this example. SWRL built-in functions such as swrlb:equal can also be used in SWRL rules.

OPEN IN VIEWER

Fig. 9.

An example of SWRL rule.

OPEN IN VIEWER

Fig. 10.

An example of environment rule.

OPEN IN VIEWER

Fig. 11.

An example of context adaptation rule.

SWRL rules provide the ability for adaptation and context reasoning, i.e. inferring high-level context from raw context data. In this research logical rules are divided into three types:

Environment Rules: This type of rule defines complex relations between entities, and introduces the environment in more detail. An example of this type of rule is illustrated in Fig. 10. System developers will declare these types of rules based on the environment in which the system will run.

Context Adaptation Rules: These rules provide the ability to deduce high level context from raw context data. An example of this type of rule is shown in Fig. 11. This example uses real time user’s device CPU usage, and says that if the CPU usage of the user’s device is greater than 80% then the related information instance presentation type needs to be text-based in order to avoid CPU overload as a textual presentation consumes less computing resources.

Different types of raw context data can be used to infer more usable information and provide a robust adaptation.

Static Adaptation Rules: The rules that introduce the requirements for a specific maintenance activity to be fired, will be described here. Actually these rules are simple ones which say which rule should be considered in which situation. But SWRL rules regarding what should be displayed in each step of the selected routine are omitted in our proposed system and Behavior Network is responsible for this job. An example of static adaptation rule is illustrated in Fig. 12.

The rule shown in Fig. 12 says that if there is an activity for which the failure reason is DirtyAirFilter, then the related information instance will be ChangeFilter_Rule.

OPEN IN VIEWER

Fig. 12.

An example of static adaptation rule.

Reasoner module Reasoner module performs two types of reasoning. The first one is Ontology Reasoning. Using the Ontology Reasoning method, the reasoner classifies individuals based on their definitions and assumes each individual as an individual of a class. As an example, in the ontology it is stated that if an activity has a failure reason it is assumed to be a corrective activity therefore if Activity1 belongs to Activity class and it has a data property of FailureReason set to some certain value then the Reasoner infers that this activity is a corrective activity.

The second reasoning method receives raw context data from Behavior Network module, applies predefined SWRL rules on the ontology, and transmits the result information instances be displayed with data properties such as status, level of detail, text color, transparency, etc. to the behavior network.

3.4.4. Behavior network module

Once we determined the output information instance name such as Activity1_Rule with its relevant properties, a behavior network will be generated using activity set { S } as sensors like Eq. (1), activity set { G } as goals like Eq. (2) and activity instructions as middle nodes { N } like Eq. (3). Each activity holds corresponding properties of InformationInstance class stated in the proposed CAMON ontology. (1) S = { activity 1 , activity 2 , activity 3 , … } (2) G = { activity 1 _ done , activity 2 _ done , … } (3) N = { node 1 , node 2 , node 3 , … }

Each middle node has a structure like Eq. (4). c i  shows a list of preconditions for node i to be activated, a i is the node add list and d i holds its delete list. (4) node i = { c i , a i , d i , ∝ i }

A specific collection of nodes shows different steps of a maintenance procedure. If an activity contains seven steps for completion, seven distinct stages containing middle nodes will be considered in the network for that activity. Based on the value of LevelOfDetail property each stage can have one or more parallel middle nodes. Figure 13 illustrates an example of middle nodes in a maintenance task with three steps in a behavior network when the value of LevelOfDetail is inferred as high demanding more detailed instructions.

OPEN IN VIEWER

Fig. 13.

Middle nodes in a behavior network.

After generating middle nodes, successor and predecessor links will be generated for each middle node. There exists a successor link from node x to node y if node y is in the add list of node x and node x is a precondition of node y, i.e. for every proposition p ∈ a x ∩ c y there is a successor link from node x to node y. A predecessor link will be created from node x to node y when there is a successor link from node y to x or for every proposition p ∈ c x ∩ a y . Each node has an activation level α i . When a node activation level surpasses a threshold that node will be activated which causes the node source code to be executed.

This will cause the generation of a logical path from each member of sensor set { S } to the relevant member of goal set { G } . The concept is to start the process from sensors and spread an energy through links to activate the desired middle nodes in the network en-route selected maintenance task specific steps. Behavior network in this research is implemented using a graph which is surfed using Best First Search (BFS) method up to the time when module arrives to the ongoing activity step.

As shown in Fig. 14 considering that Task 1 sensor with high level of detail is the desired sensor and the technician is conducting this procedure at step 2 therefore the relevant goal is Task1_done and the behavior network returns stage 2 middle nodes including Instruction2 (Description1) and Instruction2 (Description2) with their predefined properties. First the add list of the selected sensor which are stage 1 middle nodes will be activated and they activate middle nodes of stage 2 which are intended nodes.

At last a collection of middle nodes will be sent to the Visualization method. The structure of such output collection is shown in Fig. 15. Each member of this collection includes three properties, namely, item data, text color and presentation type. Item data represents the content of the output. Text color and presentation type are display properties.

OPEN IN VIEWER

Fig. 14.

Process of retrieving instruction steps.

3.4.5. Visualization module

The Behavior Network module prepares and sends a set of output objects like the one showed in Fig. 15 to the System Core module. The System Core module receives this set and transmit them to the Visualization module. The input video stream will be obtained using the user’s device camera in the Visualization module and members of the received output information list will be augmented on this video stream. Then the processed video stream including augmented information will be displayed on the user device display screen. Therefore the final user can make use of the maintenance scene enriched with virtual added guidance in order to complete the intended instruction.

OPEN IN VIEWER

Fig. 15.

Transmitted pack.

4. Experiment

The proposed framework provides assistance to the users to perform maintenance tasks based on AR technology. An experiment has been conducted in a simulated maintenance environment to validate the output results of the proposed framework. In the simulated environment, the user tries to change the air filter of a car engine in different contexts. The results of the experiment are as follows.

In the first experiment, a novice BDM engineer is changing the air filter of a car engine. The engineer’s preferred color is set as red and his device CPU usage is obtained as 75 percent. As Fig. 16 illustrates, a red box and a guidance string introducing the location of the air filter container is shown to the user with a user preferred color and a symbolic presentation due to the high CPU usage.

The engineer continues to the next step of the task in the second experiment. The difference with the previous step is that CPU usage drops to 30% and the battery level shows 80%. Therefore, the intuitive presentation is selected to help the user opening the screws and circled arrows will be shown over the screws location to show the user that the screws need to be opened anticlockwise at this step (Fig. 17). A caution sign is also presented on the scene as an alert to the novice user of the system.

OPEN IN VIEWER

Fig. 16.

Change air filter – step 1.

OPEN IN VIEWER

Fig. 17.

Change air filter – step 2.

In the third experiment, the user device battery level drops to 25% in the second step which caused the presentation type to be changed to symbolic, and also the user preferred color changed to green. So, the arrows and caution sign are deleted and the simple green circles and a text are presented on the scene instead, as shown on Fig. 18.

The forth experiment starts when the user surfs to the third step of the task. Considering the user preferred color as blue, CPU load at 25%, and the battery connected to AC power, the intuitive presentation is selected as the presentation type. Therefore, a blue 3D arrow with related guidance to open clamps is presented on the scene (see Fig. 19).

OPEN IN VIEWER

Fig. 18.

Change air filter – step 2.

OPEN IN VIEWER

Fig. 19.

Change air filter – step 3.

A general maintenance environment is being modeled in this research. We implemented a middle-ware to produce sample data to evaluate the proposed framework. Using this middle-ware the same sample data is produced for two cases: One for the time when the ontology is used alone, and the other for the time when the proposed framework in this paper uses a mixture of ontology and behavior network.

Sample data in each ontology is divided into two categories: First, when an expert technician is running the system resulting in a low level of detail. Second, the time that a technician with low expertise level is using the system which results in high level of detail output information.

For each of these cases the relevant ontology is filled with the desired number of individuals as Table 1 in order to evaluate the performance of the proposed framework.

A performance evaluation is conducted in order to compare the system run-time using each method. For first time the comparison is made between ontology alone and the proposed framework in this paper considering user expertise level as high. Run-time to achieve the output information instances and their related properties in this case is shown as Table 2.

OPEN IN VIEWER

Fig. 20.

Run-time comparison when LoD is low.

As shown in Table 2 and Fig. 20, in the beginning where the number of activities is small, the run-time of ontology alone method is better than the proposed framework. But as the number of activities grows, the application run-time using ontology increases exponentially. On the other hand, the run-time of the proposed framework in this paper increases slightly and the average reduction rate of 2.756 seconds in run-time is obtained when using this method.

This evaluation is conducted in another case when the user’s expertise level is low, which leads the activity level of detail to be high and causes greater number of information instances to be retrieved. The run-time for this case is shown in Table 3.

As shown in Table 3 and Fig. 21, the proposed framework achieves a better score in both cases. The average reduction rate in run-time considering this case is 3.828 seconds.

OPEN IN VIEWER

Fig. 21.

Run-time comparison when LoD is high.

We achieved a total average reduction rate of 42% in the initial run-time when the proposed framework in this paper is used which is more satisfactory to the end users.

In this research a review of simple AR-based maintenance systems, context-aware systems and AR-based context-aware maintenance systems has been conducted. A context-aware framework for AR systems in maintenance domain is proposed. The proposed framework employs ontology and behavior network.

Ontology models the maintenance context and defines entities in the real environment and their inter-relations. Applying logical SWRL rules and reasoning based on the current user’s context in order to infer and provide context adaptive output to the final user is also the responsibility of ontology and the implemented reasoning engine.

The need for defining SWRL rules to select output information collection according to the ongoing activity step is ignored in the ontology, and turned over to a behavior network instead which selects the collection of output information to be superimposed on the screen based on the current activity step. This will reduce the number of SWRL rules defined in the ontology and decrease the time required to run the framework.

There are things in this research to be improved as future work. First, although context-awareness helps to improve the usability of AR systems, there is a lack of research in this field in maintenance context and there are different context parameters that can be employed to provide a better adaptive user interface to the users. Second, the lack of an authoring tool is sensed in this research in order to provide a bi-directional interaction tool between technicians and the system to provide maintenance procedure steps by technicians and make corrections on data provided by developers. Third, with the help of context-awareness, a suggested list of technicians with the same skill and location is provided, but there is a need for a tool to provide remote collaborative communication between technicians and the members of this list. Finally, there is a need to evaluate the proposed adaptive user interface in terms of usability, learnability, time required for job completion, etc.