an aspect-oriented programming-based approach to software development for fault detection in...

Computer Standards & Interfaces 32 (2010) 141–152

Contents lists available at ScienceDirect

Computer Standards & Interfaces

j ourna l homepage: www.e lsev ie r.com/ locate /cs i

An Aspect-Oriented Programming-based approach to software development for faultdetection in measurement systems

Pasquale Arpaia a,b,⁎,2, Mario Luca Bernardi a,1, Giuseppe Di Lucca a,1,Vitaliano Inglese b,c,2, Giovanni Spiezia b,c,2

a Department of Engineering, University of Sannio, Corso Garibaldi 107, 82100 Benevento, Italyb CERN, Dept. AT (Accelerator Technology), Group MEI, CH 1211, Genève 23, Switzerlandc Department of Electrical Engineering, University of Naples, Federico II, Via Claudio, Napoli, Italy

⁎ Corresponding author. Department of EngineeringGaribaldi 107, 82100 Benevento, Italy. Tel.: +39 082305840.

E-mail addresses: [email protected] (P. Arpaia), m(M.L. Bernardi), [email protected] (G. Di Lucca), Vita(V. Inglese), [email protected] (G. Spiezia).

1 Tel.: +39 0824 305804 17; fax: +39 0824 305840.2 Tel.: +41 22 76 76635; fax: +41 22 76 76230.

0920-5489/$ – see front matter © 2009 Elsevier B.V. Aldoi:10.1016/j.csi.2009.11.009

a b s t r a c t
a r t i c l e i n f o
Available online 22 November 2009

Keywords:Automatic measurement systemsFault detectionAspect-Oriented ProgrammingSoftware development

An Aspect-Oriented Programming-based approach to the development of software components for faultdetection in automatic measurement systems is proposed. Faults are handled by means of specific softwareunits, the “aspects”, in order to better modularize issues transversal to several components. As a case study,this approach was applied to the design of the fault detection software inside a flexible framework formagnetic measurements, developed at the European Organization for Nuclear Research (CERN). Experi-mental results of software modularity and performance measurements for comparing aspect- and object-oriented solutions in rotating coils tests on superconducting magnets are reported.

, University of Sannio, Corso4 305804 17; fax: +39 0824

[email protected]@cern.ch

l rights reserved.

© 2009 Elsevier B.V. All rights reserved.

1. Introduction

Nowadays, test automation is a must for product quality andreliability, both in industry and in research. Intelligent measurementsystems are used deeply in delicate tests involving several instruments.One of their key issues is the capability of assuring a proper terminationto the test process.With this aim, a suitable fault self-detection softwareturns out to be an adequate reaction to anomalous working [1]. Devicesprovide information about their status continuously and, in case ofabnormal working, a fault condition is pointed out.

Software implementation of fault detection is a well-knownstrategy for dealing with failures caused by both hardware andsoftware faults [2]. Compared to hardware implementation, it hasthe advantage of higher flexibility and cost effectiveness. Today, it isa widely used technique, and emerging application areas for cost-effective dependable systems will further increase its importance[3]. Thus, the software implementation of a fault detector affectsthe overall system quality, in particular maintainability andreusability. The implementation analysis of state-of-the-art auto-

matic measurement systems highlighted that fault detection isusually scattered all over different software components, mainlywith reference to devices' hierarchy. This means that often theconcrete classes of virtual devices contain duplicated code for faultdetection, thus making harder their comprehension, testing, andmaintenance.

Nowadays, the development of the software for an automaticsystem exploits usually such as object-oriented [4,5], component-based [6,7], and agent-based development techniques [8]. They aimat organizing the software system in modules by reducing theircoupling, and maximizing their internal cohesion. Anyway, cross-cutting concerns can negatively affect the quality of even wellmodularized systems [9]. Crosscutting concerns are related toissues, such as the fault detection in an intelligent measurementsystem, transversal to many modules. This causes the duplication ofparts of very similar code in several different modules, bycompromising maintainability and reusability.

In this paper, the Aspect-Oriented Programming (AOP) isproposed for the development of software components for faultdetection implementation in order to overcome such drawbacks.The crosscutting concerns related to fault self-detection of a largemeasurement software project are separated and handled better byencapsulating them into specific modules called aspects. In thisway, the reusability of system modules improves. As experimentalcase study, the development of an AOP-based fault self-detection inthe Flexible Framework for Magnetic Measurements (FFMM) [10]at the European Organization for Nuclear Research (CERN) ispresented. In particular, in the following Sections, (i) an AOPbackground, (ii) the proposed AOP-based fault detector for automatic

mailto:[email protected]





http://dx.doi.org/10.1016/j.csi.2009.11.009

http://www.sciencedirect.com/science/journal/09205489

142 P. Arpaia et al. / Computer Standards & Interfaces 32 (2010) 141–152

measurement systems, (iii) the fault detector design for the flexibleframework for magnetic measurements at CERN, (iv) a case study onrotating coils fault detection, and (v) conclusions are reported.

2. AOP background

Aspect-Oriented Programming (AOP) [11] is an extension of theobject-oriented paradigm that provides new constructs for improvingthe separation of concerns and supporting their crosscutting. AOPdefines a kind of program unit, the aspect, for specifying concernsseparately, and rules for weaving them to produce the overall systemto be run. Like a class of objects, an aspect introduces a new user-defined type into the system's type hierarchy, with its own methods,fields, and static relationships to other types.

Usually, an AOP system can be seen as composed by two parts: (i)one consisting of traditional modularization units (e.g. classes,functions) and referred as the base system or core concern, and (ii)the other one consisting of aspects, encapsulating the crosscuttingconcerns involved in the system, and usually referred as the secondaryconcerns.

The features AOP provides for implementing crosscutting concernsin aspects can be classified in:

• dynamic crosscutting features: implementation of crosscuttingconcerns by modifying the runtime behaviour of a program;

• static crosscutting features: modification of the static and structuralproperties of the system.

Dynamic crosscutting is implemented by using pointcuts and ad-vice. An advice is a code fragment executed in specified points at theprogram runtime. The points in the dynamic control flow where theadvice code is executed are called join points. A pointcut defines theevents (such as method call or execution, field get and set, exceptionhandling and softening) triggering the execution of the associatedadvices. A pointcut is an expression patternmatched during executionto join points of interest. Every advice is associated to a pointcutdefining the join point(s) at which it must be applied. Advice code canbe executed either before, after, or around the intercepted join point.A join point shadow is the static counterpart, in the code, of a joinpoint; equivalently, a join point is a particular execution of a join pointshadow. Aspects and base program are composed statically by aweaving process.

The weaver is the component of an AOP programming languageenvironment (such as AspectJ [12]) responsible for the weavingprocess. The weaver inserts instructions at join point shadows toexecute the advice to be applied at the corresponding join points. Theweaver may need to add runtime checks to the code inserted at a joinpoint shadow in order to perform parameters binding and otherrequested computations.

Fig. 1. A simple A

The static crosscutting features of AOP implement crosscuttingconcerns by modifying the static structure of the system. An aspectcan introduce newmembers (i.e. fields, methods, and constructors) toa class, or interface; change or add parents for any class or interface;extend a class from the subtype of the original super-class orimplement a new interface. These features are called intertypedeclarations.

An example of a straightforward AOP program (an AO version ofthe ‘Hello World’ program implemented in AspectJ [13]), enlighteningAO basic working, is reported in Fig. 1. In the figure, the code of theclass HelloWorld and the aspect GreetingsAspect are reported.The aspect defines a pointcut and two advices. The callTellMes-sage()captures calls to all public static methods with names thatstart with tell. In the example, the pointcut captures the calls totell(...) and tellPerson(...) methods in the HelloWorld

class taking any arguments. The two advices, one before and one after,associated to the callTellMessage() pointcut will cause, respec-tively, the printing of the "Good morning!" and "Bye Bye!" textstrings just before and after each message printed by the tell() andtellPerson() methods.

3. AOP-based fault detector for automatic measurement systems

In the following, the proposed AOP-based approach to thedevelopment of software for fault detection in automatic measure-ment systems is described. In particular, (i) the measurement faultanalysis, and (ii) the fault detector architecture are highlighted.

3.1. Measurement fault analysis

Most common faults in an automatic measurement system can beclassified according to the sources and the synchronization of therelated handling operations.

According to the sources, faults can be classified as arising from:

• hardware devices, when devices are in a faulty internal state due tohardware anomaly or to an external condition. Device internal faultdetection can scale from very basic internal information to verycomplex routines forcing the device in different states. Correspond-ingly, concrete aspects of the fault detection subsystem must becapable of intercepting relevant changes in the device status,decoding them, and broadcasting high-level faults description tothe interested components.

• the measurement environment, when themeasurement environmentis compromised by external or internal alterations.

• software components, when software components are in any non-consistent state, owing to an incorrect use violating pre-conditionsand/or post-conditions, or to the presence of unresolved orundiscovered bugs.

O program.

143P. Arpaia et al. / Computer Standards & Interfaces 32 (2010) 141–152

According to the synchronization of the related handling operations,faults can be classified as:

• synchronous, when an anomalous operation is attempted. In thiscase, the following policies can be applied, according to thecriticality level and the kind of the fault:

∘ k-times retry: some operations are retried until the device goesback in a consistent state, without any performance constraint onthe operation. As an example, an initialization reset tried severaltimes during a slow start up of a multimeter.

∘ multicast warning and continue: for operations requested inwrong conditions, requests can be ignored by issuing only anotification warning. As an example, a digital scope is triggeredwhen previous data digitization is not ended, or when a stop or anabort is issued on an already stopped instrument.

∘ multicast fault and deny operation: for operations to not beexecuted when specified faults occur. In this case, the operation isdenied and the fault information is sent to the pertinentcomponents in order to be properly handled.

∘ multicast an immediate shutdown request and deny operation: forthe most critical situation when a fault on a critical operation in arisky device should be blocked at the lowest level. Moreover, sincethe systemas awhole is to be shutdowngracefully as fast as possible,a high priority request of system shutdown is sent to the faulthandler component. These faults are handled suitably by wrappingoperations through concrete pointcuts, bounded to around advicesdefined by abstract aspects of the fault detector component,

• asynchronous: when hardware or environment anomalies, in awhatever moment not synchronized with the measurement opera-tions generate faults forcing devices in faulty states usually detectedby suitable monitoring. The detection is based on field accesspointcut expressions bound to the decoding logic used to detectchanges in the status of devices.

3.2. Fault detector architecture

The proposed architecture is based on:

• a fault detection subsystem, designed for:− monitoring the ‘health’ state of the measurement system's

component devices;− catching software faults such as stack overflow, live-lock,

deadlock, and application-defined faults, as soon as they occur;• a fault notification subsystem, responsible for− receiving the sequence of occurring faults from all the system

components constantly;− storing the diagnostic history and providing access to other

components or to external humans in order to react to faultyevents adequately.

These two subsystems exploit three key components: (i) a Fault-Detector aspect hierarchy, allowing the code related to the faultdetection logic to be removed from the modules implementing thevirtual devices; (ii) fault decoder tables, needed by concrete aspects fordecoding status representation specific of concrete VirtualDevices;(iii) FaultListeners in order to dynamically and to bind (obliviously)components responsible for the fault management to the ones actingas fault sources.

4. Fault detector design for the flexible framework for magneticmeasurements at CERN

The design of proposed AOP-based architecture for developingfault detection software components in automatic measurementsystems is presented in the context of the Flexible Framework forMagnetic Measurement (FFMM) [10], under development at CERN incooperation with the University of Sannio. FFMM is based on Object-

Oriented Programming (OOP) and Aspect-Oriented Programming(AOP), and aims at supporting the user in developing software for thetest of superconducting magnets for particle accelerators, maximizingquality in terms of flexibility, reusability, maintainability, andportability, without neglecting efficiency, vital in test applications.FFMM gathers from the user the requirements about a measurementtask to be accomplished, and helps produce software capable ofcarrying out the requested task.

In Fig. 2, the proposed FaultDetector hierarchy is reported, byillustrating the static relationships among Virtual_Device classes, theFaultDetector aspect with its sub-aspects, and some concrete virtualdevices (DigitalIntegrator and EncoderBoard). In the figure, the roleplayed by the classes FaultDecoder and FaultTable is highlighted.

For the sake of the clarity, an example related to two devices,typical of magnetic measurement applications, a digital integrator(namely the Fast Digital Integrator, FDI [14]), and an encoder board,with the corresponding classes FastDI and EncoderBoard, respectively,is reported in the same figure. Encoded fault information is extractedfrom the FastDI device by context interception and is decoded bymeans of a concrete class DigitalIntegrator_FaultDecoder. The aspectDigitalIntegrator_FaultDetector is hence responsible for enforcingfault management policies according to the fault kind. It defines theappropriate listener and, when a device is registered in theFaultDetector, an instance of the listener is subscribed to the concreteinstance of the device. The FaultDetector is responsible for definingpointcuts capturing creation and destruction of devices. TheVirtual_Device hierarchy models and organizes all the physical devicesinvolved in the measurement process. Each device has an internalstatus; modifications to such a status are captured by means ofconcrete FaultDetector sub-aspects. The sub-aspects execute the logicneeded to decode the modification, as well as an appropriate method(i.e. fireFault, fireBadParameter, fireError,…) to broadcast fault infor-mation to the concrete FaultListener registered during the devicecreation and to all the other interested components.

Each FaultDetector sub-aspect is associated to the main devicescategories and defines the mapping logic towards concrete deviceclasses belonging to the same family. Indeed, the coarseness of themapping between aspects and concrete devices allows the faultdetection logic to be reused for similar devices very flexibly, as well asto be encapsulated in a few of modules (instead to be spread all overthe device classes).

In Fig. 3, the different levels of fault interceptions, according to thefault types, are depicted. The bottom level takes care about very specificissues and features of concrete devices to be encapsulated in dedicatedsub-aspects. At the middle level, concrete aspects perform continuousmonitoring of devices' status, by means of appropriate pointcutexpressions and decoders. The top level includes abstract aspects,implementing the fault detection logic, reusable in concrete sub-aspects.

The fault notification strategy has been implemented by means ofa publish–subscribe architecture, such as shown in Fig. 4, in the case ofthe device EncoderBoard. In particular, the cooperation among Fault-Detector and its sub-aspects (in order to associate handlers to faultsources in the measurement system dynamically) is highlighted. Thesub-aspects of the aspect FaultHandler have the responsibility to makeaware the concrete classes of the faults occurring in the system (e.g.the TestManger is responsible for supervising the test session).

The aspect EncoderBoard_FaultHandler defines a concrete imple-mentation for the abstract slice class specific for the EncoderBoarddevices. Such an implementation is responsible for registering/deregistering the EncoderBoardFaultListener when an EncoderBoarddevice is created/destructed. Moreover, the sub-aspect also definesthe pointcut expressions to intercept and decode faults calling theappropriate fault broadcasting methods.

This solution allows fault handling logic to be reused in the super-aspects and does not force concrete classes in the system toimplement fault handling code. Any component in the system can

Fig. 2. An excerpt of the hierarchy of the proposed fault detector.


react to specific faults occurring anywhere in the system by carryingout the related handling actions.

The concrete classes (TestManager or any other componentsinterested in monitoring faults) are oblivious of being faults' handlers,thus the monitoring relationships can be changed by acting simply onaspect mapping. Commonalities among different fault handling logicscan be factored out in the aspects, while multiple observations ofdifferent kinds of faults can be easily accomplished by defining severallisteners for a single concrete class.

In the following, two typical scenarios are discussed in order tohighlight the system behaviour at runtime. In Figs. 5 and 6, a class anda communication diagram, showing the interception of a devicecreation and the messages exchanged by key involved components,respectively, are depicted.

In Fig. 7, a sequence diagram, modelling (i) the typical behaviourafter listener registration, when faults can happen during normaldevice operations, and (ii) another typical scenario, when a deviceaccesses internal state by means of read/write operations, is reported.

While the proposed architecture is suitable for removing the faultdetection code from the devices completely, in a first pilot implemen-tation, the design team decided for not affecting the event handlingprotocol of the framework. Therefore, the code of fault and errorbroadcasting routines still lies in the component implementing thedevices. This approach was aimed at carrying out a concern-drivenadoption of AOP. From this point of view, the event handling is itself aconcern to be migrated to the AOP paradigm in a future work.

5. A case study on rotating coils fault detection

A case study was carried out to verify and asses if the softwarequality of the proposed AOP version for the fault detector was actuallyimproved with respect to the previous existing OOP version and toverify that the new AOP architecture had not a negative impact onruntime performance of the overall system (due to aspect runtimeinterception overhead). Thus an evaluation of the software qualityattribute of modularity was performed to verify the first point and

Fig. 3. Levels of faults interception.

Fig. 4. Fault notification publish–subscribe architecture.


Fig. 5. Device creation/destruction interception.


some runs of an adequately instrumented version of the system wereexecuted to verify the second point.

To fulfill the latter case the system has been tailored on the FFMM,by specifying: device under test, quantity to be measured, measure-ment instruments, measurement circuit configuration, measurementalgorithm, and data analysis. The aim was the one of handling the

Fig. 6. A collaboration scenario started by cre

exceptional events in the measurement application based on themethod of rotating coils [15]. In the following, (i) the rotating coilsmeasurement, (ii) the analysis and design of fault detection software,(iii) the modularity comparison, and (iv) the performance verification,are illustrated.

5.1. The rotating coils measurement

The measurement method is based on the “rotating coil” (Fig. 8[15]): A set of coil-based transducers is placed in the magnet bores,supported by a shaft turning coaxially inside the magnet. The coilsignal is integrated according to the Faraday's law in the angulardomain, by exploiting the pulses of an encoder mounted on the shaft,in order to get the induction field. Several coil segments are placed onthe shaft by covering the length of the magnet. Each segment, in turn,is made up by three overlapped coils: the external one measures themean field (absolute signal), while the series connection of theexternal and the central coils in opposition of phase allows the mainfield to be deleted in order to measure the field harmonics only(compensated signal). The field quality in accelerator magnets isexpressed in terms of the magnitude of undesirable harmonics.

The coil shaft inside themagnet is turned by the Rotating Unit (RU)whose motor is driven by a controller (Maxon Epos 24). The magnetunder test is supplied by power converters with digital control, withvery different capacity depending on the test conditions: tests arecarried out at cold (up to 1.9 K) and warm (room temperature)conditions by using a 14 kA 15 V and a 20 A, 135 V power converter,respectively. The current is read by a digital multimeter through ahigh-accuracy Direct Current–Current Transformer (DCCT). The coilsignals are integrated in the angular domain by digital integrators (i.e.,a Fast Digital Integrator [14], FDI, implemented by the FastDI class), byexploiting the trigger pulses coming out from a conditioning board(developed at CERN, implemented by the EncoderBoard class),

ateDevice interception on EncoderBoard.

Fig. 7. A sequence diagram showing the detection of a wrong parameter configuration of an EncoderBoard instance.


suitably processing the output of the encoder mounted on the RU. TheFDI boards, the encoder conditioning board, and the motor controllerare remotely controlled by a PC running the test program output byFFMM, produced according to a suitable script [10].

5.2. Analysis and design of fault detection software

The rotating coil testing technique is a typical application involvingseveral different devices, each one with its own state and errormessages. During the operation of the measurement station of Fig. 8,one or more faults can affect the devices at different levels. At thelowest level, a fault can influence one of the communication buses(e.g. PXI, RS-232, IEEE-488). At this level, possible faults on the busesare: (i) communication timeout; (ii) device not found on the bus; (iii)error on an open, read, write, or close command. All these kinds offaults require the data acquired up to the fault occurrence to be saved,some diagnostic information about the state of the measurementstation to be logged, and the devices to be reset in order to return backthem to a consistent state.

At a higher level, some faults can involve the devices controlledtrough the communication buses, namely the FDI, the encoder board,and the motor controllers. In particular, the FDI can be affected by thefollowing faults: (i) a timeout can occur during the time interval

between the transmission and the execution of a command, or whenthe measurement starts and the integrator waits for the trigger pulsesfrom the encoder; (ii) an inconsistency of the internal status of theinstrument; (iii) a wrong parameter value is set. The two last faultconditions can occur also for the encoder board and the motorcontrollers analogously. For the motor controller, another fault canarise from the handshake procedure on the communication bus (RS-232).

Within the proposed fault detection architecture, faults of thetype (i) and (ii) are detected by means of specific pointcutexpressions associated to around advices capturing the access tointernal devices' status and eventually sending fault events tointerested components. Conversely, the faults of type (iii) aredetected by means of pointcut expressions, associated to deviceoperations' signatures in order to enforce the constraint related toincoming parameter settings and eventually configured to enforce aretry policy.

In all these cases, the fault turns out to be fatal and requires thecomponent to be reset after saving the data and logging all theadditional information, as well as saving the bad parameter settingin order to detect this situation and ask for new parameter values.

In particular, the aspect FaultDetector realizes the infrastructureneeded to add/remove fault monitoring services on device creation/

Fig. 8. Layout of the rotating coils measurement setup [15].


destruction. Its sub-aspects provide advice logic for different kindof policies of fault handling, such as discussed in Section 4.Furthermore, such sub-aspects define pointcut expressions neededto capture interesting context in which status of device must bechecked, perform status decoding, and eventually send a fault eventby means of the logic provided by the classes FaultListener.

Figs. 9 and 10 show an excerpt of the code of the FaultDetectoradvice (and its sub-aspect related to FastDI digital integrator device)and of the DigitalIntegrator_FaultDetector.

Fig. 9. The abstract Fau

5.3. Modularity comparison

The software quality of the proposed AOP version of the faultdetector was evaluated in comparison with the corresponding OOPversion previously existing at CERN inside FFMM. With this aim, thesoftware quality attribute of modularity was assessed for both theAOP and OOP versions by evaluating (i) the percentage of lines ofsource code related to fault detection logic present in each modulewith respect to the total Lines of Code (LOC) of the same module, and

ltDetector aspect.

Fig. 10. Excerpt of DigitalIntegrator_FaultDetector.


(ii) the Degree of Scattering (DOS) and Degree of Focus (DOF) metrics[16], for each module and fault detection concern. The analysis wasfocused on the most relevant fault sources of the FFMM, i.e. themodules implementing devices.

Table 1Fault detection code in each device module and computation of DOF and DOSmetric forboth OOP and AOP versions (OOP: Object-Oriented Programming; AOP: Aspect-Oriented Programming; LOC: Lines of Code; DOF: Degree of Focus; DOS: Degree ofScattering).

Device OOP FD %LOC

OOP cloned%LOC

OOPDOF

OOPDOS

AOP %LOC

AOPDOF

AOPDOS

FastDI 15.75 10.93 0.17 0.96 0.81 0.97 0.13Maxon_Epos 18.04 9.78 0.21 0.73 0.97Encoderboard

21.53 14.27 0.28 0.62 0.98

Powersupply

18.36 12.70 0.24 0.64 0.90

Transducer 21.15 8.24 0.27 1.79 0.93Keithley2k 18.48 11.32 0.16 0.77 0.97

In Table 1, the analysis results along with the ratio of codeduplicated in the different software modules (cloned code ratio) arereported. In the OOP version of the fault detector, a high level ofcloned code exists, because in each device operation often the sametests against the internal status are requested. Conversely, in the AOPversion, this ratio is drastically reduced.

An ideal implementation of the fault detection concernwould have anull DOS and aDOFequal to 1, for each devicemodule (i.e. each device isfocused only on the base concern and does not contribute at all to thefault detector concern). Table 1 shows that the OOP version has a verylowvalueofDOF, for eachmodule (i.e. allmodules contribute to the faultdetection concern), and aDOS for the fault detection concern near to themaximum (uniformly scattered). This means that the fault detectionconcern in the OOP version has very bad values ofmodularity. Thus, anynot trivial maintenance (or evolution) is very difficult, because eachmodification could affect and require changes in many differentsoftware modules (i.e. mainly all device modules).

Instead, in Table 1, DOS values of the AOP version are near to theminimum: the fault detection concern is well modularized in one

Fig. 11. Percentage lines of code (LOC%) of fault detection concern in device modules forOOP and AOP versions.


module (the FaultDetector aspect), and each device module ismarginally involved in the concern (such as said before, this is dueto the fault and error broadcasting methods not yet removed from thedevices).

This result is better highlighted in Figs. 11 and 12. In particular, inFig. 11 the percentage LOC (%LOC) of the fault detection concern allover the device modules is compared for both AOP and OOP versions.In the figure, the ratio of the cloned LOCs in the OOP implementation,completely removed in the AOP version, is reported. Of course, thecloned code makes worst the maintainability and increases theprobability of introducing bugs in the code.

In Fig. 12, the level of DOS (a) and DOF (b) for each device modulewith respect to base system and fault detection concerns is reported.

Fig. 12. DOS (a) and DOF (b) comparisons of OOP and A

The results show a radically increasedmodularity for the AOP version,because each device module is much more focused on the baseconcern with respect to the OOP version. Moreover, the faultdetection concern is highly scattered in the OOP version (high valuesof DOS), while it is very focused in the AOP implementation (very lowvalues for DOS).

5.4. Performance verification

The case study was aimed also at verifying experimentally that theAOP architecture would not have a negative impact on runtimeperformance of the overall system (due to aspect runtime intercep-tion overhead). With this aim, the AOP system was instrumented inorder to gather execution times of the aspect overheads.

In both the versions, fault detection times related to fault decodingand handling, are present. They were filtered out from the analysis.Therefore, main attention was paid to evaluate the overheads addedby AOP interception mechanism to the fault detection time in order toassess the effectiveness of the AOP architecture, i.e. that the AOPresponse times are not worst than the OOP version.

The above described analysis was carried out by running the twoversions of the software in the same conditions. The runs wereperformed by causing some faults in the measurement stationpreviously described. Those faults were induced intentionally indifferent ways, for example by providing the devices with wrongparameter values, by interrupting the communication between the PCand the devices (device not found, or communication timeout if thecommunicationwith device had already been established), by startingthe FDI acquisition procedure without feeding the instrument withthe required trigger signal (measurement timeout) and adding a delayin the execution of some commands (command timeout).

The worst average times in several different categories of faultdetection pointcut expressions (i.e. device creation/destruction,interception of device operations) were selected, and the time spent

OP versions with respect to fault detection concern.

Table 2Worst average times spent in aspect runtime with respect to device creation/destruction and fault detection pointcuts.

Pointcut expressions Total time (ms)spent in aspect

Time (ms) spent inmatching advices

Time (ms) spentin aspect runtime

%Time spent inaspect runtime

1 EncoderBoard construction 13.029641 13.028840 0.000801 0.0062 FastDl construction 45.912234 45.893478 0.018756 0.0413 FDICluster (1 element) construction 59.062982 59.010519 0.052463 0.0894 Maxon_Epos construction 14.013891 14.011993 0.001898 0.0145 EncoderBoard destruction 10.282883 10.282652 0.000231 0.0026 FastDl destruction 18.511722 18.511302 0.000420 0.0027 FDICluster (1 element) destruction 6.034312 6.034096 0.000216 0.0048 Maxon_Epos destruction 11.045256 11.045013 0.000243 0.0029 within(EncoderBoard) && call(%) && args(...) 2.8803261 2.842784 0.037542 1.30310 withincode(FastDl) && call(plx-Nwrite) 1.146675 1.144412 0.002263 0.19711 withincode(FastDl) && call(plx-Nread) 1.486675 1.476675 0.010000 0.67312 withincode(Maxon_Epos) && execution (set%) 0.982102 0.980102 0.002000 0.20413 withincode(Maxon_Epos) && execution (get%) 0.902345 0.899015 0.003330 0.36914 withincode(Maxon_Epos) && execution (start()) 2.896735 2.886735 0.010000 0.34515 withincode(Maxon_Epos) && execution (stop()) 2.416875 2.406875 0.010000 0.414


in the aspect runtime to jump to fault detection routines wascollected. These are reported in the last column of Table 23 (inpercentage of the total time spent in the aspect).

Times needed to handle creation/destruction of devices (pointcutexpressions from rows 1 to 8) are greater than those required tohandle faults during measurement tasks (pointcut expressions fromrows 9 to 15). In the former cases, the fault detector infrastructuremust be set up for devices being created. This requires more time thanthe other kind of pointcut expressions that have only to capture thecontext of an operation, issuing a fault event if necessary. These timesare comparable to those of the OOP version, where listeners areexplicitly registered with the created devices to handle faults. In thesecases, the aspect overhead is particularly reduced with respect to theentire fault detection tasks.

Pointcut expressions ranging from row 9 to row 15 are related tofault detection during normal device operations. Their goal is tocapture all the context in which the device state changes to check itsvalidity. In the developed AOP implementation, the worst overheadsdue to aspect interceptionmechanism (see the last column in Table 2)are always less than 1.5% of the fault detection times (the worst case isfor the interception of calls to EncoderBoard device operations withcomplex arguments matching expression to check pre-conditions;related to pointcut expression at row 9).

Therefore, the suitability of such performance overhead in theconcrete measurement scenario was assessed, where all the timingconstraints were satisfied flatly.

6. Conclusions

A fault self-detector based on Aspect-Oriented programming waspresented. Such a software design integrates the Object-Orientedapproach, by adding specific encapsulation of crosscutting concerns.The proposed approach was used for the development of a faultdetector in a framework for magnetic measurement, under develop-ment at CERN. The advantages of using AOP in the development of afault detector were verified in the case of a measurement applicationbased on rotating coils for testing a superconducting magnet.

This approach allows uniformly different kinds of faults producedfrom different components to be handled. The proposed architectureallows a high level of flexibility by performing very complex andbendable runtime binding among sources and handlers of the faults,while keeping the detection code well modularized in its hierarchy.

3 The times refer to a Pentium IV 1.3 GHz machine, with 512 Mb of RAM running theinstrumented AOP version.

Another main advantage of such a technique is the maintainabilityand the reusability of the code: for each new device added to theframework, the related fault detection code is added to the faultdetection hierarchy. Since all fault detection code is well modularizedin few sub-aspects, commonalities among different fault detectionlogic are well structured and factored out. As a consequence, theFaultDetector design, with respect to ‘traditional’OOP version, exhibitsa much more centralized design, reducing code duplication andgreatly increasing the possibility of code reuse.

Finally, the proposed AOP architecture is not targeted at a specificsystem component, and the same fault detector architecture can bereused to detect different kinds of faults in different components.

Acknowledgements

This work was sponsored by CERN trough the agreement K 1464with the Department of Engineering, University of Sannio, whosesupport authors gratefully acknowledge. The authors thank PhilipLebrun, Luca Bottura, Marco Buzio, Felice Cennamo, Laurent Deniau,Juan Garcia Perez, Giancarlo Golluccio, Giuseppe Montenero, andLouis Walckiers for their useful cooperation.

References

[1] O. Postolache, J.M.Dias Pereira,M. Cretu, P.S. Girao, AnANN fault detectionprocedureapplied in virtual measurement systems case, Proc. of IEEE Instrumentation andMeasurement Technology Conference, IMTC/98 vol. 1 (May 18–21 1998) 257–260.

[2] M. Catelani, S. Giraldi, A measurement system for fault detection and faultisolation of analog circuits, Measurement 25 (2) (March 1999) 115–122.

[3] P. Arpaia, G. Lucariello, A. Zanesco, Automatic fault isolation by cultural algorithmswith differential influence, IEEE Trans. on Instrumentation and Measurement 56(5) (Oct 2007) 1573–1582.

[4] S.J. Bosch, in: M. Fayad, D. Schmidt, R. Johnson (Eds.), Design of an Object-orientedFramework for Measurement Systems Domain-specific Application Frameworks,John Wiley, ISBN: 0-471-33280-1, 1999, pp. 177–205.

[5] S. Wang, K.G. Shin, Constructing reconfigurable software for machine controlsystems, IEEE Trans. on Robotics and Automation 18 (4) (Aug 2002) 474–486.

[6] J.M. Nogiec, J. DiMarco, S. Kotelnikov, K. Trombly-Freytag, D. Walbridge, M.Tartaglia, A configurable component-based software system for magnetic fieldmeasurements, IEEE Trans. on Applied Superconductivity 16 (2) (Jun 2006)1382–1385.

[7] J.E. Beck, J.M. Reagin, T.E. Sweeney, R.L. Anderson, T.D. Garner, Applying acomponent-based software architecture to robotic workcell applications, IEEETrans. on Robotics and Automation 16 (3) (Jun 2000) 207–217.

[8] N.R. Jennings, Agent-based computing: promises and perils, Proc. of the fifthInternational Joint Conference on Artificial Intelligence (IJCAI), 1999, pp. 1429–1436.

[9] C. Pfister, C. Szyperski, Why objects are not enough, Proc. First InternationalComponent Users Conference (CUC), Jul 1996.

[10] P. Arpaia, L. Bottura, M. Buzio, D. Della Ratta, L. Deniau, V. Inglese, G. Spiezia, S.Tiso, L. Walckiers, A flexible framework for generating magnetic measurementautomatic systems at CERN, Proc. of IEEE Instrumentation and MeasurementTechnology Conference, I2MTC/07, Warsaw, Poland, May 1–3 2007.


[11] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Videira Lopes, J.M. Loingtier, J.Irwin, Aspect-Oriented Programming, Proc. of the 11th European Conference onObject-Oriented Programming (ECOOP), vol. 1241, Springer-Verlag, 1997, pp.220–242.

[12] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm,W.G. Griswold, An overviewof Aspect J, Proc. of the 15th European Conference on Object-OrientedProgramming (ECOOP), Lecture Notes in Computer Science, Budapest, Hungary,vol. 2072, 2001.

[13] http://www.eclipse.org/aspectj/.[14] P. Arpaia, A. Masi, G. Spiezia, A digital integrator for fast and accurate

measurement of magnetic flux by rotating coils, IEEE Trans. on Instrumentationand Measurement, vol. 56, Apr. 2007, pp. 216–220.

[15] L. Bottura, K. N. Henrichsen, “Field measurements”. CERN Accelerator School,Erice, CERN report, 2004–2008.

[16] Eaddy Marc, Zimmermann Thomas, Kaitlin D. Sherwood, Garg Vibhav, Gail C.Murphy, Nagappan Nachiappan, Alfred V. Aho, Do Crosscutting Concerns CauseDefects? IEEE Trans. on Software Engineering (May 16, 2008).

Pasquale Arpaia was born in Napoli, Italy, on February 2,1961. He took MD and PhD in Electrical Engineering atUniversity of Napoli Federico II where he taught Electricaland Electronic Measurements until 2001. Then, he becameAssociate Professor at University of Sannio. From August2005 he is also Project Associate for the Large Hadron
Collider at European Organization for Nuclear Research(CERN). He served as Associate Editor for the Subject Areas“Quality and Statistical Methods” and “Test” of IEEETransactions on Electronics Packaging and Manufacturing.Now he is Editor of the Subject Area “Digital InstrumentsStandardization” for the Elsevier Journal Computer Standards& Interfaces. His main research interests include ADC
modelling, testing, and standardization, measurement systems on geographic networks,statistical-based characterisation of measurement systems, evolutionary algorithms fordiagnostics, and digital instruments for magnetic measurements in particle accelerators.In this field he has published more than 100 scientific papers in journals and national andinternational conference proceedings.

Mario Luca Bernardi received the Laurea degree in Computer Science Engineeringfrom the University of Naples “Federico II”, Italy, in 2003 and the Ph.D. degree inInformation Engineering from the University of Sannio in 2007. Since 2003 he has beena researcher in the field of software engineering and he is author of several paperspublished in journals and conference proceedings. His main research interests includesoftware maintenance and testing, software reuse, software reverse engineering andreengineering, with particular interest on systems developed by the aspect-orientedparadigm. He has served as reviewer of papers submitted to conferences and journals inthe field of software engineering, software maintenance and program comprehension.

Giuseppe A. Di Lucca received the Laurea degree inElectronic Engineering from the University of Naples“Federico II”, Italy, in 1987 and the Ph.D. degree in ElectronicEngineering and Computer Science from the sameUniversityin 1992. He is currently an Associate Professor of ComputerScience at the Department of “Ingegneria” of the Universityof Sannio. Since 1987 he has been a researcher in the field ofsoftware engineering and his list of publications containsmore than 80 papers published in journals and conferenceproceedings. His main research interests include softwareengineering, software maintenance, software testing,reverse engineering, software reuse, software reengineering,software migration, aspect-oriented software development,

and web engineering. He serves both as a member of the program and organizingcommittees of conferences, and as reviewer of papers submitted to some of the mainjournals and magazines in the field of software engineering, software maintenance andprogram comprehension.

Vitaliano Inglese was born in June 1976, in Benevento,Italy. He took his MD in Automatic Control Engineering, inMay 2006. He carried out his thesis at CERN in theDepartment AT/MTM, from October 2005 to May 2006,on the development and metrological characterization of aFast Digital Integrator for magnetic measurements based
on rotating coils. He worked at CERN from June 2006 toOctober 2006, in the Department AT/MTM, on the furtherdevelopment of FDI. In November 2006, he started his PhDat department of Electrical Engineering of the University ofNaples Federico II. He is developing his research activitiesat CERN in the department AT/MEI. His main researchinterests include digital signal processing and magnetic
measurements on particle accelerators.

Giovanni Spieziawas born in Naples, Italy, on January 1981.He received the M.D. and the Ph.D. degrees in electronicEngineering from the University of Naples Federico II. ThePh D. activity, the design and the development of a FastDigital Integrator, were carried out at the EuropeanOrganization for Nuclear Research (CERN). He is currently
with the Engineering Department at CERN, where he isinvolved in the development of a new nuclear radiationsensor and a new position sensor prototype. His researchinterests include electronic design, digital signal processing,and magnetic measurements on particle accelerators.

an aspect-oriented programming-based approach to software development for fault detection in...

Documents