Context-aware systems have long found application in everyday use cases, assisting users with their daily lives. Technical service covers any tasks concerning the maintenance, diagnosis, and repair of industrial machinery. It is a more speci c domain that would also bene t from the introduction of context-aware systems. This domain requires the ltering and consumption of a vast amount of information resources. Employing semantic technologies enables engineers to more precisely nd information as compared to full-text search. However, it still requires a search query to be actively formulated to the system. This paper applies the principles of context-aware systems to information systems for the technical service, where the technician is guided though the service process in uenced by various sensors de ning their current context. An implementation based on an established ontology for context-aware systems is presented that integrates with semantically enriched documentation.
In the technical domain, the trouble-shooting and maintenance of advanced machinery is a complex task. Technical documentation describes the service-related tasks for these machines and typically comprises some thousand pages of information for a single machine. Consequently nding relevant information bits for a speci c fault is di cult and time-consuming.
In the last years, many semantic information systems were introduced in
the technical domain to support technicians during service tasks [
Repair instructions
Circuit diagrams
T3: T1: Repair / Functional Assembly test
T2: Diagnosis
Operating instructions
Functional descriptions Measurement information
In this paper, we propose the extension of semantic information systems by context-aware techniques, that provide the users with relevant information for their current tasks. For example, a service technician in a trouble-shooting task is unlikely to be interested in maintenance information when formulating a query. More generally, by knowing and tracing the context of a working engineer and their corresponding use of technical documentation, the system will be able to provide more relevant information. In Figure 1 the typical trouble-shooting work ow of a service technician is depicted. Essentially, the work ow is partitioned into three sub-tasks: 1. The functional test assures that the failure is actually present, 2. The diagnosis aims to nd the cause of the failure, and 3. The repair and assembly xes the failure. In every task, the service technician has di erent information needs, i.e. is interested in di erent types of documentation. The most common documentation types are depicted along the edge of the gure. For example, during the task functional test the service technician needs the operating instructions in order to know how the failing function is operated properly. Context-awareness tries to guess the actual task of the technician and to recommend the best- tting information for the current situation.
The paper is organized as follows: Context-awareness is based on the interpretation of sensors. Thus, we rst describe speci c sensors with respect to technical service scenarios. For an implementation the context-awareness needs to be represented within the semantic system. Therefore, we introduce an ontological representation and show its application in a selected case study. The paper is concluded with a summary and planned future work.
Context-aware Systems in Technical Service
Modeling a specialized application domain such as technical service in a
contextbased system requires the use of various sources of information. In a
contextbased system, this information is provided by sensors that can be physical, but
in this case mostly are virtual and logical (following the de nition in [
Equipment Competence Relative Location
Resource Availability
Location
Machine Type
Process Step
Recently Viewed
Resources
Service Record
Environment Machine-relative location One of the most common sensor types in everyday use of context-based systems is the location sensor, using AGPS to determine a person's position with an accuracy of up to a few meters.
Location information is also valuable in the target domain, but required on a ner scale. Its use becomes evident when dealing with machines that exceed a certain installed size as it for instance is the case with o set printing machines. Knowing the module at which the engineer currently is located at enables a context-based information system to narrow down the relevant documentation to that speci c part.
Engineer equipment Another factor to consider is the equipment available to the engineer. This includes both the available tools in the engineer's toolkit as well as the devices they have available to consume documentation: augmented or virtual reality displays and expert systems may not be available on all device types or require special gear.
Using this information enables a timely detection of faults that are not remediable with the currently available material and improves clarity in the software system by hiding information that can not be displayed. Information and resource availability The applicability of documentation items is further determined by the resources at the engineer's disposal. Most importantly, it needs to be determined if the engineer has Internet access to reach further materials on a company network. For problems requiring in-depth analysis and triage, the ability to contact o -site support sta may be required as well.
Engineer competence level Given the ever increasing complexity of modern appliances, training engineers is expensive, both nancially and in terms of time consumption. The context can factor in the engineer's competence level to o er additional guidance for lesser experienced engineers while not disturbing the work ow of seasoned mechanics with basic knowledge. Additionally, the system can sense when a procedure is potentially unsafe if performed by untrained sta .
Step in the service process This logical sensor captures the step the engineer is currently working on to in uence the choice of documentation provided. As service processes are usually provided by the manufacturer and to be followed in a speci c order, the position in the overall process can be determined.
Consideration should be given to the level of detail used for modeling the process. The inclusion of atomic steps like removing a screw would incur unnecessary modeling complexity.
History of viewed documents Together with the current process step, the previously used information within this task is an valuable sensor. The already consumed information spans the knowledge and status of the technician and can also be used to deduce the next steps in the service process. Environment at the repair site Much like the engineer equipment sensor provides information about the resources made available by the engineer, this sensor describes the environment at the work site. This information is important as the environment can be vastly di erent when working in a specialized workshop or on-site at the customer's premises. The latter location will most likely not have specialized equipment for advanced repair scenarios. 3
Ontological Representation of Context Awareness
There are various instances of existing ontological context models, such as the
ontologies COBRA-ONT [
ContextEntity CompEntity
Location
User
Activity
Resource
Machine Case
Engineer RelLoc Site
Diagnosis
… Repair
InfoRes EnvRes Tool
In the outlined technical service scenario, most classes are intuitively reusable:
We extend Person with an Engineer class representing the technician working
on a machine. An instance of this class will have several properties for
identi cation (using SKOS' skos:prefLabel [
To be able to further model the technical service domain, we also employ a few other entity classes, directly sub-classing ContextEntity. First, a Resource is de ned as a resource that is available to or required by the engineer. Such a resource can be any kind of information (InformationResource), a Tool, or an EnvironmentalResource. Examples for information resources could be documentation (like sections of a manual, schematics, or wiring diagrams), expert systems, or the possibility to contact other support sta for further consultation. While tools are items contained in the engineer's toolkit, environmental resources are to be provided at the service location (service lift, expensive diagnostic utilities). The Location class provided by CONON is used to model the machine's location as well as the engineer's relative location. Its Site sub-class is instantiated for each work site to set providesResource properties to denote available resources. The other sub-class, RelativeLocation, is to be used to capture the current machine-relative location of the engineer. Finally, a Case class which is added as a computational entity represents a service case linking engineer, location, and machine. It also contains information on the current state in the process, modeled as instances of CONON's Activity class. We de ne a set of activities representing the service process: FunctionalTest, Maintenance, Diagnosis, Repair, etc.
Given the tso namespace (technical service ontology) and ns for the target application ontology, an exemplary minimal scenario could be as follows: ns:SmallToolkit a tso:Tool . ns:ServiceLift a tso:EnvironmentalResource . ns:Machine_1 a tso:Machine . ns:Engineer_1 a tso:Engineer ;
tso:competenceLevel 4 ; tso:providesResource tso:SmallToolkit . ns:Workshop_1 a tso:Site ; tso:providesResource ns:ServiceLift . ns:Case_1 a tso:Case ; tso:locatedAt ns:Workshop_1 ; tso:servicedBy ns:Engineer_1 ; tso:machine ns:Machine_1 ; tso:currentStep tso:Diagnosis .
An Engineer (Engineer 1) has access to the SmallToolkit resource. Their competence level in this case is modeled as an integer and at level 4. The service case (Case 1) takes place at Workshop 1 which provides a ServiceLift to work on Machine 1. 4
To test the modeled ontology, we employ a small and understandable technical domain, in this case bicycles. We use the namespace pre x of bts (short for bike technical service) for framing the concepts of this domain. The example encompasses several bicycle models and contains information about repair steps and resources ful lling the engineer's information needs while performing them.
We develop a demonstration application for the use by the service technician in the eld. It has access to the ontology in order to read and write the context state and access the contained information resources. After setting initial parameters for the case, the application knows what process the engineer is about to begin, as an example diagnosis of faulty headlights on a bike. Initially, the currentStep property of the Case instance is FunctionalTest (c.f. Figure 4).
Funct.
Test
Diagnosis
For every step of the process, the application queries the ontology of the semantic information system for relevant information, depending on the current context state. This task is performed by the semantic search engine as outlined in the introductory chapter. Context information additionally in uences the results, for instance the engineer's competence level should be taken into consideration to ensure they can pro ciently perform the actions suggested by the retrieved information resources. This functionality can be implemented using a SPARQL query that yields only resources matching Engineer 1's level of competence for instance by using its FILTER functionality.
After reviewing the usage documentation, the current step changes, and so does the context. In the rest of the process, relevant resources for the next steps (diagnosis and repair) are retrieved, until a second functional test results in a working lighting system. 5
In this paper, we motivated the introduction of context-based systems into the technical service domain. We proposed a basic ontology that provides a framework for modeling service steps and entities involved in the process of servicing industrial appliances. It can be easily integrated into semantic information systems that use ontologies to represent their semantically enriched documentation as well. In combination, such an application can be used to provide precise information to technicians without the need to manually invoke search operations.
Related work can be found both in di erent domains as well as system types:
The application of context-aware information systems was proposed for instance
in the medical domain [
The focus of our approach lies in ontology reuse and alignment. Based on
an existing lean upper-ontology, we in turn implement a exible domain-speci c
layer. Future work will keep this aspect in mind: Modeling the remaining sensor
types such as machine history can be done by aligning the established PROV
ontology [
Acknowledgements The work described in this paper is supported by the Bundesministerium fur Wirtschaft und Energie (BMWi) under the grant ZIM KF2959903BZ4 "Mobile, Sprach- und MR-gestutzte Dokumentation und Diagnose im Technischen Service (Service Troi)".