Data collection

As mentioned in Chapter 1, on the RADAR system the event logs are stored in an internal database in XML format. These event logs are the main input for the analysis conducted in this chapter.

2A modelling formalism that can provide a highly simplied and abstract view on processes [12], [11]

2.4. Data collection 23

Figure 2.3: UML model of XML log le

2.4.1 XML Log Data

Each system that is connected to the PRS system generates log les that record every operation done on the system on a daily basis. These systems are identied by an unique identier. A Log.XML le for each day of the system under operation is stored. Figure 2.3 represents the UML class diagram of XML log les [21].

Each system can create one or more XML log les, which in turn consists of one or more LogEntry XML elements. Each log le has the same XML data structure.

This is shown in the UML model as the classes System, XMLFile, LogEntry, and their relationships.

The elements contained in a LogEntry are explained in Table 2.1.

The LogEntry element can be classied into three types:

• User Message: The entry will be logged when a message is shown to the end user on the screen, e.g, Geometry restarting.

• Command: The entry will be logged when a command is invoked in the sys-tem, either by the system itself or by the user. A command always has a Name attribute which represents the corresponding name of the given com-mand. In some cases, a command can also have a Params attribute which gives more information about the logged command, i.e., the voltage values, or even requested, completed type of commands.

• Warning & Errors: These entries are logged when the systems observe devi-ations from the expected behaviour and it reports warnings, usually followed

Elements of Log Entry

Description

Index It refers to the index of the log entry. For each log le, the index starts from 1.

Unit According to the system architecture, the CV system consists of several subsystems, and these subsystems comprise of units, like Session Manager, Reviewing, X-Ray control etc. The value for this element corresponds to the unit that generated this log entry.

Date On which date the message was recorded by the logger.

Time At what time the message was recorded by the logger.

Severity The severity of a log entry. It can either be information, error, or warning. Fatal is another kind of severity though uncommon.

EventID It uniquely identies each message generated from a particular system unit.

Description Description (information) of the event.

Memo More detailed information about the event is included. Sup-pose a log entry description eld refers to the start of some ser-vice, then the corresponding memo eld could depict the software module related with the started service.

SystemMode The system can have several modes, namely Startup, Shutdown, Shutdown Completed, Warm Restart, Normal Operation, and Field Service.

LogID They are about the logger. LogID refers to the identier of the logger, while line number and thread describes the properties of the logger from the software perspective.

Line Number Thread

Module They are related to source code of the software inside the system. The module records the directory of the executable le.

SourceFile

Table 2.1: Descriptions of the Elements in a Log Entry

2.4. Data collection 25 by related errors.

Information, User Message and Warnings & Errors LogEntries are not used in the remainder of this chapter, however the Command is used for the conversion of event logs because it represents the actions executed on the system by the user. Out of the system modes presented in Table 2.1, only Field Service mode and Normal Operation mode will be considered. Field Service is the mode in which the FSE is performing the necessary operations/actions for maintenance of a system. Normal Operation is the mode when the user (doctor/laboratory technician and even FSE) operates the system. For example, when the doctor does a surgery on the patient, the system logs commands selected by the doctor and commands/events generated automatically by the system under normal operation mode. The FSE can also exe-cute actions under Normal Operation mode, i.e. when testing the functionality of the system, performing verication of its behaviour.

The event logs are selected from the Allura Xper systems considering the replace-ment of a FRU, using dierent perspectives such as version of the system, release, region and geography distribution.

A complicating factor in the case of the X-Ray system's log les is the highly com-plex and exible execution of activities. At the same time, the granularity of events stored in log les is at the lowest level.

2.4.2 Case denition

In this section we are going to describe in detail the corrective maintenance case which is the basis of the data collection step. In the situation of a system mal-function the result is a corrective maintenance case which, as described in Section 1.2.2 is usually associated with the replacement of a unit in the system (FRU) or software updates. The FSE will visit the hospital and perform diagnostics on the system to identify the cause of the failure and most of the times replace a part or a set of parts. The process of such a replacement represents the focus of our analysis:

what the FSE does on the eld during the diagnosis of a faulty system. Whether it is the part replacement, performing calibration or verication of the system, all the activities that the FSE performs represent the FSE process. Every corrective maintenance case is recorded in the job sheets database, CSDWH (described in Sec-tion 1.2.2) that contains informaSec-tion about the customer complaint, replaced FRU, maintenance hours, etc.

A corrective maintenance in which a FSE is required to service a faulty system rep-resents a corrective maintenance call. These calls are coming from the customer who complains about the malfunction of the system. Each call has an unique entry in the CSDWH database and is stored with information like the callID, open date and close date, the id of the system on which maintenance was performed (congID), etc.

As Figure 2.4 presents, the analysis starts with selecting a part of interest and

iden-Figure 2.4: Data collection

tifying the set of systems on which this part had been replaced, i.e. for this analysis the chosen part is the Converter Velara 8E, presented in detail in Section 2.6.1.

The reason for choosing the Converter Velara 8E is that the mean time to repair (MTTR) for the replacement of this part is much longer than expected, and it also has a large variation across dierent calls.

A part can be replaced on more systems and each system can have associated mul-tiple calls, it can be the case that the same part had to be replaced several times on the same system during a period of time. Furthermore, each call has an associated set of log les. The data collection represents the selection of log les corresponding to each call related to the replaced part.

The time window of a case is dened to be k days before and after the call open date and call close date. This is a parameter that can be changed in the data collection phase. Because sometimes it happens that the calls are stored in the database by the engineers with dierent dates than they were performed, because the systems store the logged data at later dates and because in some cases the customer may not report the problem immediately, it was decided to consider this time window. In the case of the Converter Velara 8E part, since it is a critical component and it is expected that a customer immediately calls after experiencing a problem, k was cho-sen to be three days before the call open date and three days after the call close date