3756
IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 60, NO. 12, DECEMBER 2011
A Model-Driven Domain-Specific Scripting Language for Measurement-System Frameworks Pasquale Arpaia, Lucio Fiscarelli, Giuseppe La Commara, and Carlo Petrone
Abstract—A measurement-domain-specific language, which is based on a model-driven paradigm for measurement-testprocedure definition, instrument configurations, and task synchronization, is proposed. This formal language, which is particular for a specific measurement field, aims at specifying complete, easyto-understand, easy-to-reuse, and easy-to-maintain applications efficiently and quickly by means of a script. The script is checked and integrated into the existing software framework automatically by a specific parser–builder chain, in order to produce the measurement application. Constructs for abstracting key concepts of the domain allow the test engineer to write more concise and higher level programs by natural language-like sentences in a shorter time without being a skilled programmer. As an experimental case study, the proposed language has been applied to the flexible framework for magnetic measurements at the European Organization for Nuclear Research (CERN). Index Terms—Automatic programming, automatic test equipment, automatic test software, computer interfaces, computer languages.
I. I NTRODUCTION
O
VER THE PAST few years, several advanced software approaches have made the development of measurement applications faster and less expensive [1]–[4]. The primary interesting research trends are to: 1) increase the reusability of existing software by means of a framework [5]–[9]; and 2) speed up and make less expensive the code development by easier user-friendly programming languages [10]–[13]. As far as the research trend on frameworks is concerned, traditional software systems, which are built as monolithic entities developed from scratch, often have difficulty providing a convenient flexible behavior and are therefore less common than domain-specific frameworks [6]. A software framework is an abstraction where common codes providing generic features can be selectively overridden or specialized by the user, in order to produce a new application with specific features. Frameworks can be seen as a special case of software libraries
Manuscript received October 29, 2010; revised March 29, 2011; accepted March 30, 2011. Date of publication July 7, 2011; date of current version November 9, 2011. This work was supported in part by the European Organization for Nuclear Research and in part by the University of Sannio under Agreement K 1464. The Associate Editor coordinating the review process for this paper was Dr. Thomas Lipe. The authors are with the Department of Engineering, University of Sannio, 82100 Benevento, Italy, and also with the Department of Technology, Group of Magnets Superconductors Cryostats, European Organization for Nuclear Research, 1211 Genève, Switzerland (e-mail:
[email protected];
[email protected]). Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/TIM.2011.2149310
maximizing the reusability of codes and reducing the development cost of new software products. The basic ideas of software frameworks can be applied to many contexts, and their usefulness is evident in the measurement domain, where software technologies are exploited massively. An ideal framework, in order to capitalize on the work already carried out in the past, includes all the effort to develop a new procedure and then provides a solid basis for all subsequent uses. However, a significant part of the production costs of new automatic measurement systems is related to the development and maintenance of software applications [7]. Usually, test engineers are experts in the measurement field, but in order to produce a software application for their purposes, they should also have programming skills. This task has to be committed to software developers. However, the process of identifying requirements for test procedures, coding the requirements, and then verifying the operation of the application, can be an expensive burden. The ideal solution would be the production of a concise and bug-free specific script [8] by test engineers directly [9]. This solution gives rise to the requirement for a software tool to simplify the application design and implementation. In the context of the research trend on measurement languages, graphical programming environments for developing measurement and test systems, which are characterized by graphical icons and wires symbolizing the data flow (such as LabView [10]), are very popular. The underlying approach of the programming language (e.g., the G for Labview [11]) emphasizes the objects involved in the application and the data exchange, with less emphasis on the representation of the temporal sequence, even if both serial and parallel executions are possible. Conversely, in scientific and academic communities, scripting languages are commonly used and preferred [12]. They point out the order of operations and allow the temporal constraint in the measurement application to be managed easily [13]. Advanced software techniques (e.g., software framework, scripting, new programming languages) have been exploited recently in the area of magnetic-field measurements [14]. These solutions lead to maximum software-component reuse, but final users have to manipulate code written in extensible markup language and Python. Successful examples of new programming languages for improving measurement applications and reducing the development effort can also be found in networkperformance testing [15] and in monitor and control systems [16]. These results cannot be applied directly in the measurement domain; however, they suggest a way to make complex software systems usable by less specialized end user.
0018-9456/$26.00 © 2011 IEEE
ARPAIA et al.: DOMAIN-SPECIFIC SCRIPTING LANGUAGE FOR MEASUREMENT-SYSTEM FRAMEWORKS
3757
Fig. 2. Generic structure of a measurement framework.
Fig. 1. Test-engineer and application-user roles in a measurement software framework [13].
In this paper, we take these points into consideration and exploit model-driven-engineering (MDE) concepts [17] in proposing a measurement-domain-specific scripting language (MDSL) for defining test procedure scripts, configuring instruments, and synchronizing measurement tasks. In particular, in Section II, background information on the main concepts of measurement-system frameworks and domain-specific approaches for programming languages is given. In Section III, the requirements, the basic ideas, and the architecture of the MDSL are highlighted. Finally, in Section IV, the experimental results of the MDSL implementation inside the flexible framework for magnetic measurements (FFMM) [18] at the European Organization for Nuclear Research (CERN) are illustrated. II. BACKGROUND A. Measurement-System Frameworks In Fig. 1, the different roles of test-engineer and application users in a generic measurement software framework are defined. In the first phase, the test engineer prepares the measurement script, which is a high-level description of the measurement procedure. Then, the script is processed by the framework in order to obtain the final executable measurement application. In the second phase, the final user executes the application, interacts with the system by providing the required input and configuring the hardware setup, and finally supervises the automatic execution of the measurement. In Fig. 2, the overall structure of a generic measurement framework is pointed out. The script, which contains all the information about the required measurement (e.g., device under test, instruments, connections, test procedures, inputs, outputs, displays, and so on), is first checked, in order to verify its correctness. Then, it is translated by the code builder into the source code in the same language of the library modules of the framework. At this stage, the compiler is able to merge all the components, leading to the production of the executable application. Along with less important data, the script includes main vital information about: 1) the devices selected; 2) their configuration and setup; and 3) a set of actions to be carried out sequen-
tially or concurrently. Assuming that a test engineer responsible for writing the script does not have adequate software skill, suitable tools are provided in order to simplify the production of the code and to manage it in a simple and intuitive way [13]. In particular, the proposed domain-specific scripting language helps the test engineer to concentrate on the design of the test procedure rather than on its implementation by thinking at a high level, namely, in terms of the devices, their configuration, and the measurement algorithm. In this way, a means to interact directly with the underlying framework structure and take the maximum advantage of its use is provided. B. Domain-Specific Languages In recent years, MDE [17], which is a software-development methodology, creating models and abstractions closer to some particular domain concepts rather than computing or algorithmic concepts, has been proposed. The main purpose is to increase its productivity by simplifying and standardizing the process of design and implementation. This paradigm finds a concrete application in domain-specific languages (DSL): “Model-driven engineering technologies offer a promising approach to address the inability of third-generation languages to alleviate the complexity of platforms and express domain concepts effectively” [17]. In all branches of science and engineering, generic or specific approaches can be distinguished. A generic approach provides a general solution for many problems in a certain area, but such a solution may not be optimal. Specific approaches generally provide a better solution for a smaller set of problems. In computer science, one of the applications of this dichotomy is the “domain-specific languages” versus “generic programming languages.” According to this, a DSL can be defined as a programming language or a executable specification language offering, i.e., through appropriate notations and abstractions, expressive power focused on (and usually restricted to) a particular problem domain. The domain can be seen as a specific setting with an implicit set of artifacts, actors, and processes [19]. Therefore, the key characteristic of the DSL is its focused expressive power. The benefit of a DSL in contrast with a general-purpose language is the capability of providing appropriate built-in abstractions and notations. In particular, the DSL uses terms derived from a model created for a particular problem domain and used for defining components or complete solutions to be used in the domain [20]. A summary of the advantages of the DSL follows: 1) to express solutions in the idiom and at the level of abstraction of the problem domain, so that domain experts
3758
IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 60, NO. 12, DECEMBER 2011
can understand, validate, modify, and often even develop programs by themselves directly; 2) to enhance the quality, productivity, reliability, maintainability, portability, and reusability of the software; 3) to allow a direct validation at the domain level, i.e., the language rules can include the domain regulation. Conversely, some drawbacks also arise: 1) the cost of designing, implementing, and maintaining a new language, as well as related to the development tools; 2) the burden of learning a new language; 3) the potential loss of efficiency compared with a handwritten code. A new language involves the development of a new parser, a builder, and all the tools for a profitable use. This discourages the growth of new DSLs [21]. The break-even point is more easily reached if these components and tools are already available as generic elements and they have to be only specialized to the domain of interest [22]. By carefully designing the constructs of the language in a simple way and with meaning related to domain concepts, the new language will be easily learned and exploited by the operators in the domain. Recently, practical [23], [24] and also theoretical [25], [26] tools for DSL development have been proposed, demonstrating the increasing interest in such a method. Examples of the useful exploitation of DSL concepts can be found in home automation [20], network-performance testing [15], and network-device programming [27]. Generally, a program written in a DSL is called a domainspecific description (DSD). Such a program is compiled, interpreted, or analyzed by a domain-specific processor. After the compilation, a textual- (e.g., in a general-purpose programming language) or binary-format output is obtained. Furthermore, external or internal DSLs can be defined. An external DSL is a domain-specific solution, which is represented in a natural-like language separate from the main programming environment. It has its own custom syntax and a specific parser (i.e., to be implemented). An internal (or embedded) DSL instead expresses new domain constructs within the syntax of a general-purpose language, which is suitably modified for this purpose. III. M EASUREMENT-D OMAIN -S PECIFIC L ANGUAGE A. Requirements In advanced test environments, new measurement applications are currently developed in two basic ways: 1) starting from scratch and writing the application with standard languages by using an integrated development environment (IDE); or 2) exploiting a framework structure and leveraging the work already done. The second option is better when numerous different applications have to be produced in a long-term period. A framework, particularly if following the object-oriented paradigm, helps the programmer by providing a high level of abstraction and allowing code reuse. Nevertheless, only quite skilled programmers can exploit these features. Conversely, the proposal deals with providing test engineers by an easy and fast way to write measurement scripts. This goal is achieved by developing a measurement-domain-
Fig. 3. MDSL process according to the pattern “source-to-source transformation.”
specific language (MDSL), with the main requirements of: 1) defining logical, numeric, and temporal conditions; 2) performing conditional branching; 3) defining events based on measurement values or attribute changes, time changes, external event notifications, or user inputs; 4) subscribing and unsubscribing to events and responding to them with behaviors including messages to users or commands; 5) setting, configuring, and commanding the devices; 6) enabling, configuring, and disabling framework services; and 7) interacting with the user through the interfaces provided by the underlying framework [28]. B. Basic Ideas The basic idea for conceiving a DSL for measurement applications arises logically from the analysis of a typical measurement procedure. Usually, a measurement description should be expressed by a few specialized commands concerning device management, the temporal sequence of actions, and data treatment. At the level of the abstraction of commands to send to physical (i.e., hardware devices connected by a bus) or virtual objects (purely software components providing some services), the measurement description can be seen as a script, i.e., a relatively short program composed by a sequence of instructions controlling the operation and performing a work task all in one batch. The power of a script organization of the test program, instead of a graphical representation (such as in LabView), is mainly related to the immediacy of translating a well-defined procedure in a logically ordered set of commands. The proposed approach consists of defining a new programming language, which is based on measurementdomain-specific descriptions (MDSDs), for producing batch applications within a software framework. As any programming language, an MDSD has its own lexicon, syntax, and semantics. A low level of complexity is provided by keeping the lexicon bounded and often using mnemonic words from the domain, and by simplifying the syntax through straightforward command structures, e.g., the commands for piloting a device are divided into categories of similar meaning (e.g., settings, execution, and so on) and with the same use. The new language is combined with the software basis of an existing framework by decodifying the MDSL code through a custom parser (i.e., the measurement-domain-specific parser) first and then by translating it to the target language through a builder (i.e., the measurement-domain-specific builder). Such an approach can be ascribed to the creational pattern “sourceto-source transformation” [29] (see Fig. 3). C. Architecture The proposed MDSL was based on a separated semantic model [19], which was conceived as a part of the framework
ARPAIA et al.: DOMAIN-SPECIFIC SCRIPTING LANGUAGE FOR MEASUREMENT-SYSTEM FRAMEWORKS
Fig. 4.
3759
Semantic model and proposed architecture.
domain model. Generally, the semantic model consists of a network of concepts and the relationships between those concepts. Concepts are particular ideas or topics from the user perspective with which the user is concerned. In the MDSL, it describes the measurement-test-procedure core structure and determines its behavior. The semantic model is detached from the MDSL in order to: 1) think about the semantics of the domain without getting tangled up in the MDSL syntax or parser; 2) be able to test the semantic model by creating objects in the model and manipulating them directly; 3) follow an incremental approach by starting with a simple internal MDSL and then adding an external MDSL; 4) be able to evolve the model and the language separately: a change in the model can be explored without changing the MDSL by adding the necessary constructs to the MDSL, or new syntaxes for the MDSL can be experimented by just verifying the creation of the same objects in the model. The separation of the semantic model and the MDSL syntax mirrors the separation of the domain model and presentation suggested in [30]: the MDSL can be thought as another form of user interface. In Fig. 4, another benefit of using a semantic model is highlighted: The code generator or builder is decoupled from the parser, a code generator can be written without having to understand anything about the parsing process, and it makes possible independent testing. D. Measurement-Domain-Specific Parser Parsing is a strongly hierarchical operation [31]. When a text is parsed, the chunks are arranged into a tree structure. Let us consider the simple structure of a list of events in a measurement procedure: Events EncBoard_StartTrigger EB_ST MrController_StartRotation MC_SR End In this composite structure, a list contains events with their own name and code. The explicit notion of an overall list is missing, and each event is still a hierarchy of events with their own name symbol and code string.
Therefore, the MDSD script is represented as a hierarchy, i.e., the “syntax tree” (or “parse tree”). A syntax tree is a much more useful representation of the MDSD than the words; it can be manipulated in many ways by walking up and down in the tree. Basically, the measurement-domain-specific parser reads the textual MDSD, builds syntax trees, and translates them to obtain the measurement-domain-specific semantic model (see Fig. 4). The syntax tree is built by means of a specific grammar, i.e., a set of rules describing how a stream of text is turned into a syntax tree. Grammars consist of a list of production rules, where each rule has a term and a statement of how it gets broken down. The measurement-domain-specific parser is designed by defining the grammar rules taken from the measurement domain. Such a parser analyzes the MDSD script and provides the measurement-domain-specific builder by an exhaustive specific semantic model. E. Measurement-Domain-Specific Builder The model-driven architecture (MDA) is an approach to the software development of the Object Management Group [32]. A tool implementing the MDA concept allows developers to produce models of the application and generate the corresponding code for a target platform by means of suitable transformations. The MDA is sound groundwork for automatic code generation. As a matter of fact, the basis of automatic code generation is to read project artifacts (such as class diagrams, activity diagrams, and requirement documents) and turn them into a meaningful and correct source code. The implementation of automatic code generators relies on the fact that most artifacts are created in the early stages of software. These artifacts are repetitive and have design patterns; thus, they can be automated. Most simple implementations of automatic code generators use only the class diagram to create a source code. Class diagrams have been the easiest to implement because of the inherited design pattern to object-oriented languages such as Java and C++. In general, code-generation techniques give rise to the production of a nonoptimized code. However, in a delimited command vocabulary such as the measurement domain, a specialized builder allows an easiness/efficiency tradeoff not too costly in terms of computational costs. In the MDSL architecture (see Fig. 4), the measurementdomain-specific builder is responsible for the code generation
3760
IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 60, NO. 12, DECEMBER 2011
according to the MDA approach. From the domain-semanticmodel instance produced by the measurement-domain-specific parser, specific situations are represented in order to create the corresponding code. The builder, rather than a class diagram, takes from the parser the structured semantic model as input. It is able to recognize the classes, the methods, and the sequence of actions to be carried out, as well as to translate the model into the final code. IV. C ASE S TUDIES An experimental case study, which was conceived specifically for testing the proposed MDSL in an actual measurement application, was envisaged in the frame of the FFMM [33] at CERN in collaboration with the University of Sannio. In the following, after recalling the structure of the FFMM, the MDSL implementation and application results are highlighted by referring to two practical examples: superconducting-magnet testing and permeability measurements. A. FFMM At CERN, the series field tests for the nearly 2000 superconducting and resistive magnets of the Large Hadron Collider (LHC) have been carried out by means of a control-andacquisition measurement system, which is developed under highly variable conditions of evolving hardware and software configurations and measurement requirements. The test software suffered a long evolutionary path from the original version. This suggested the launch of a research project with the University of Sannio for developing a new software platform for control and data acquisition [18], i.e., the FFMM, in order to match the new measurement requirements and manage the challenge of new instrumentation. The design of the FFMM was based on the following basic ideas [34]. 1) Flexibility is achieved by means of code reusability: The rapid variations of measurement requirements due to the frequent occurrence of different small batches of tests are satisfied by redesigning software modules. 2) Reusability is achieved by an object-oriented approach and modularity: A suitable design of the code allows modules to be reused. 3) The incremental building of module libraries: Once the modules can be reused, a finite application domain will be covered in a finite time. 4) The standardization of software structures and modules: A definition of code structures and patterns gives rise to the production of standard modules to be reused easily. 5) The predefinition of a software structure of the test program, which is organized in standard modules: Such an organization provides the user with templates to be filled for generating new codes. Correspondingly, the fundamental principle underlying the FFMM architecture is the decoupling of software components through three main layers (see Fig. 5). • Base services layer—communication and service packages. This layer implements the necessary foundations
Fig. 5.
Multilayered FFMM architecture.
Fig. 6.
MDSL implementation in the FFMM.
for communications, utilities (such as useful algorithms and class libraries), and an operating-system (OS) service abstraction package. • Core services layer—virtual-device and event handling, and logging/fault detection. Virtual devices are software components modeling in the FFMM, i.e., the concrete devices to be orchestrated during measurement processes. Event handling was implemented to let a virtual device and other software components to obtain the needed information about the state of components of their interest. Logging/fault detection are responsible for monitoring the state of the component devices and catching software faults such as stack overflow, livelock, deadlock, and application-defined faults as they occur. • Measurement services layer—Test management and acquisition synchronization are able to create groups of tasks to be synchronized to well-defined events (e.g., start and stop or device events). B. MDSL Implementation The implementation of the MDSL inside the FFMM (see Fig. 6) exploits several main features of the Eclipse Modeling
ARPAIA et al.: DOMAIN-SPECIFIC SCRIPTING LANGUAGE FOR MEASUREMENT-SYSTEM FRAMEWORKS
Fig. 7.
3761
Specific grammar example of the MDSL in Xtext.
Project [22], [24], which is a modeling framework and codegeneration facility for building tools and other applications based on a structured data model consisting of: 1) interfaces and implementation classes for all the classes in the model plus factory-and package (metadata) implementation classes; 2) implementation classes that adapt the model classes for editing and display; 3) a properly structured editor that conforms to the recommended style for Eclipse Modeling Framework (EMF) model editors and serves as a starting point from which to start customizing. In particular, the MDSL has been developed by the Eclipse features Xtext and Xpand [24]. Xtext is a tool for the development of DSLs and textual programming languages. It provides a language-specific IDE and, in addition to common parser generators (such as, e.g., JavaCC [35] or ANTLR [36]), generates: 1) an incremental ANTLR3-based parser to read models from the MDSD script; 2) a serializer to write models back to text and produce the measurement-specific semantic model; 3) a linker to establish cross links between model elements; 4) an integration of the language into the Eclipse IDE. In Xtext, the script structure can be set up by embedding the rules of the new language-specific grammar. In Fig. 7, an example of MDSL grammar implementation is shown. A script (between the hot words BEGIN _ SCRIPT and END _ SCRIPT) can contain measurement task statements only. A task (between the
hot words BEGIN _ MTASK and END _ MTASK) can be composed by device definition statements (starting with DEF), device configuration statements (starting with CFG ), or device command statements (starting with CMD), and the order must be respected. In the statement declaration organized by typology, e.g., the definition statement in Fig. 7, the list of permitted methods is specified. If the item is preceded by the symbol “|,” the order is not mandatory. Basically, a grammar tree can be defined in Xtext by adding the grammar rules from the generic to the specific ones. In particular, the example is tailored to a fast digital integrator (FDI) and a motor controller, which are specific devices often exploited in magnet testing. Some of the IDE features, either derived from the grammar or easily implementable, are syntax coloring, model navigation, code completion, outline views, and code templates. Xpand is a tool specialized for code generation based on EMF models and used as a builder to produce the C++ code suitable for the FFMM. Each object already defined in the grammar (Xtext) has to be treated by the domain-specific builder (Xpand). The rules of code generation are specified in the Xpand file. In Fig. 8, two examples of builder rules, which are for the FDI instrument and the motor controller, are pointed out. By reiterating the same process for all the devices supported by the FFMM, the whole MDSL has been developed. In general, all the commands related to standard acquisition boards, multimeters, digital integrators, precision positioning stages, motor controllers, and encoder boards are already implemented. In addition, some commands related to user-interface programming and data presentation are included [37]. The cost to add
3762
IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 60, NO. 12, DECEMBER 2011
Fig. 8. Domain-specific-builder rules of the MDSL in Xpand.
Fig. 9. Superconducting-magnet test script.
a new device into the specific grammar of the language can be quantified in about 20 new lines of codes for the creation and about ten lines for each method. C. Superconducting-magnet Testing The FFMM is employed currently at CERN for characterizing the superconducting magnets of the LHC. In particular, a significant measurement effort is devoted to the investigation of the dynamic field error of the main dipole magnets [38].
Rapidly varying magnetic fields are measured by designing a new measurement station with high-speed rotating coils units and FDIs [39]. A rotating shaft, which is composed of 12 rotating ceramic segments each holding three tangential equal parallel pick-up coils, equips both the apertures of the magnet. One coil is normally used to measure the dipole field component (i.e., the so-called “absolute” signal), whereas the connection in series opposition with a second coil provides cancelation of the dipole (“compensated” signal) and ensures higher noise rejection for the measurement of harmonic error
ARPAIA et al.: DOMAIN-SPECIFIC SCRIPTING LANGUAGE FOR MEASUREMENT-SYSTEM FRAMEWORKS
3763
Fig. 10. Measured normal sextupolar “decay” and “snapback” as a (left) function of the time and the (right) measured current for different supply current cycles (data are scaled to be compared).
components. In the current arrangement, the signals from consecutive segments are connected in series by three groups of four “supersegments,” which are aimed at limiting the number of necessary integrators to six per aperture. Two motors provide a rotation rate up to 8 r/s in order to get signals at the desired time resolution. The absolute and compensated signals from each supersegment are input to the integrator, measuring the magnetic flux. The integrators are provided by the trigger signal from the two angular encoders, i.e., one for each motor, through an encoder board. The magnet supply current is read directly from the WorldFIP interface of the power converter and synchronized with the acquisition trigger by means of a timing board. In Fig. 9, the MDSL script as a whole for the procedure of superconducting-magnet test is shown. The script is composed of four tasks: 1) “DEVICES _ DEFINITION” for pointing out the devices to be used; 2) “DEVICES _ CONFIGURATION ,” where the device connections are configured; 3) “DEVICES _ SETTING ” for selecting the measurement parameters; and 4) “MEASUREMENT,” where the actual measurement is started and stopped. In particular, the measurement is carried out by using five different devices: 1) a set of FDIs (FDI _ CLUSTER); 2) an encoder board (ENCODER _ BOARD); 3) a motor controller (MAXON _ EPOS); 4) a power generator (POWER _ CONTROLLER); and 5) a timing board (TIMING _ BOARD ). In the device definition task, each instrument is declared with a unique name as a string. In the device configuration and setting tasks, the configuration/setting methods are called with the requested parameters suggested by the IDE during the script writing (usually strings or numbers). The measurement task contains the commands related to the actions of the devices (e.g., START, WAIT, STOP, etc.), and their argument is usually the device name as a string. After the definition, each task is added to the execution tree [13], where, in this case, only a sequential run is needed. Each task section contains a small number of methods (usually less than 15). In general, these methods are implemented into the C++ class controlling the specific device. The MDSL inherits this kind of methods from the host framework classes by taking benefit of the suggestion and the check of the arguments to be passed and the right use of the device methods in the script (e.g., for MAXON _ EPOS motor device, WAIT can be used only after START, and START can be used only after SET).
In Fig. 10, the measured integral sextuple component is shown as a function of the time and the current. In both the plots, the data are scaled by a constant value in order to make comparable the curves and emphasize the “decay” and “snapback” phenomena [40], which is typical in superconducting magnets. In particular, the measurements at 2 kA and 6 kA, having common power history parameters, are shown. The plots are obtained after data postprocessing by other tools (MATLAB). In the example, the data are treated as a 32-bit floating point and stored in the American Standard Code for Information Interchange format in order to simplify the exchange among different tools. The MDSD script for superconducting-magnet test emphasizes the power of the proposed approach. With less than 50 code lines (a compression ratio of 1:10 compared with C++) organized in a few coherent sections, a whole measurement application involving several different devices can be produced. By taking into account the reduction in code lines and with the help of specific grammar rules embedded into the IDE, measurement software applications are easier to produce than in standard programming languages. D. Permeability Measurement In the following, the MDSL script performing the permeability measurement by means of a split-coil permeameter is described [41]. The permeameter is composed of two coils wound in a toroidal shape, allowing a specimen of the material under test to be wrapped. One coil is needed to excite the field and the other one to capture the flux. The measurement is carried out through a data acquisition board, a voltage-controlled power supply for the excitation coil of the permeameter, two FDIs to acquire the flux and the current, and a CERN proprietary encoder board to manage the encoder pulses and to feed the trigger signal to the FDIs. After the setup of the devices, the measurement algorithm can be expressed by the following steps: 1) demagnetize the specimen; 2) start acquisition of flux and current; 3) start the generation of one cycle of the signal controlling the power supply;
3764
IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 60, NO. 12, DECEMBER 2011
Fig. 11. Permeability measurement MDSL script.
Fig. 12. Permeability measurement results for different current ramp rates: (left) 0.5 A/s and (right) 0.01 A/s.
4) wait for the completion of the actual current cycle; 5) stop the acquisition of the flux; 6) start the generation of the next current cycle and go to step 3 or, if the maximum value of current is reached, stop the acquisition; 7) end of test. The measurement algorithm aforementioned is codified in the script in six tasks. In Fig. 11, the script structure is shown.
The commands in each task are omitted in order to emphasize the script structure and make it more readable. The first task to be active is D EMAGNETIZATION. At the end of this task, the execution passes to the S ET _N EXT _C YCLE task (series execution); S ET _N EXT _C YCLE sets up the actual cycle of current and starts the C URRENT _C YCLE by throwing the event NEXT _ CYCLE . C URRENT _C YCLE first starts the task S TART _ACQUISITION that enables the acquisition of flux and current, begins the generation of the actual current cycle, and
ARPAIA et al.: DOMAIN-SPECIFIC SCRIPTING LANGUAGE FOR MEASUREMENT-SYSTEM FRAMEWORKS
then stops the acquisition by throwing the event STOP _ CYCLE. The task S TOP _ACQUISITION triggers a new execution of S ET _N EXT _C YCLE that restarts the loop up until the last scheduled current cycle, or enables the E ND _T EST to set the devices on standby. In contrast with the previous example, in this case, the task execution tree is more complicated and is composed of serial and parallel tasks also started by events. Simultaneous tasks can be managed in the MDSD script at a very high level of abstraction. The execution tree of serial and parallel tasks has to be described in the script simply by using the task-related commands (i.e., ADD _ TASK , ADD _ TASK _ AFTER _ TASK , and ADD _ TASK _ AFTER _ EVENT ). The control of the race conditions is delegated by default to a specific software component, i.e., the software synchronizer, which is implemented in the host language [13]. The proposed method allows the production of complex measurement applications by a composition of simpler steps: After the definition of the basic tasks, a test engineer can arrange them into an elaborate layout without increasing the script complexity. In Fig. 12, the results of two measurements of the same steel specimen are shown: the effects of eddy currents can be appreciated at different current ramp rates. The plots are obtained after data postprocessing by using other tools (MATLAB). V. C ONCLUSION A new measurement-domain-specific language with specialized constructs concerning the automation of measurement procedures is proposed. The technique is based on the MDE concepts and DSL solutions. The basic idea is to assist unskilled programmers in producing concise and error-free measurement applications, resulting in improved applications and reduced development effort. This is accomplished by using scripts written in a high-level and domain-representative language. A set of domain rules can be embedded in the language definition with the advantage of preventing errors in the early phases of the development. The on-field applications of the new technique point out the benefits in terms of simplicity, effectiveness, and flexibility in the measurement software applications production. Thus far, user feedback has been positive, and the positive user experience is fostering wider use. ACKNOWLEDGMENT The authors would like to thank L. Bottura, M. Buzio, F. Cennamo, V. Inglese, G. Montenero, F. Romano, and L. Walckiers for their useful contribution. R EFERENCES [1] A. Bondavalli, A. Ceccarelli, L. Falai, and M. Vadursi, “A new approach and a related tool for dependability measurements on distributed systems,” IEEE Trans. Instrum. Meas., vol. 59, no. 4, pp. 820–831, Apr. 2010. [2] D. J. Johnson and P. Roselli, “Using XML as a flexible, portable test script language,” in Proc. IEEE Syst. Readiness Technol. Conf., Sep. 2003, pp. 187–192. [3] A. Kalicki, L. Makowski, A. Michalski, and Z. Staroszczyk, “Distributed measurement systems-A web system approach: Part 1 [Instrumentation Notes],” IEEE Instrum. Meas. Mag., vol. 11, no. 2, pp. 50–56, Apr. 2008.
3765
[4] A. Kalicki, L. Makowski, A. Michalski, and Z. Staroszczyk, “Distributed measurement systems—A web system approach: Part 2 [Instrumentation Notes],” IEEE Instrum. Meas. Mag., vol. 11, no. 6, pp. 44–51, Dec. 2008. [5] J. Bosch, “Design of an object-oriented framework for measurement systems,” in Domain-Specific Application Frameworks, M. Fayad, D. Schmidt, and R. Johnson, Eds. Hoboken, NJ: Wiley, 1999, pp. 177–205. [6] R. Rajsuman, N. Masuda, and K. Yamashita, “Architecture and design of an open ATE to incubate the development of third-party instruments,” IEEE Trans. Instrum. Meas., vol. 54, no. 5, pp. 1678–1698, Oct. 2005. [7] Z. Guo, P. Chen, Y. Feng, Y. Jiang, and F. Hong, “ISDP: Interactive software development platform for household appliance testing industry,” IEEE Trans. Instrum. Meas., vol. 59, no. 5, pp. 1439–1452, May 2010. [8] E. Bean, “Defect prevention and detection in software for automated test equipment,” IEEE Instrum. Meas. Mag., vol. 11, no. 4, pp. 16–23, Aug. 2008. [9] J. L. Anderson, Jr., “How to produce better quality test software,” IEEE Instrum. Meas. Mag., vol. 8, no. 3, pp. 34–38, Aug. 2005. [10] Product Information: What is NI LabVIEW? Jan. 2011. [Online]. Available: http://www.ni.com/labview/whatis/ [11] G Programming Reference Manual, Jan. 2011. [Online]. Available: http://www.ni.com/pdf/manuals/321296b.pdf [12] Scripting Languages and NI LabVIEW, Jan. 2011. [Online]. Available: ftp://ftp.ni.com/pub/devzone/pdf/tut_7671.pdf [13] P. Arpaia, L. Fiscarelli, G. La Commara, and F. Romano, “A petri netbased software synchronizer for automatic measurement systems,” IEEE Trans. Instrum. Meas., vol. 60, no. 1, pp. 319–328, Jan. 2011. [14] J. M. Nogiec, J. Di Marco, S. Kotelnikov, K. Trombly-Freytag, D. Walbridge, and M. Tartaglia, “A configurable component-based software system for magnetic field measurements,” IEEE Trans. Appl. Supercond., vol. 16, no. 2, pp. 1382–1385, Jun. 2006. [15] S. Pakin, “The design and implementation of a domain-specific language for network performance testing,” IEEE Trans. Parallel Distrib. Syst., vol. 18, no. 10, pp. 1436–1449, Oct. 2007. [16] M. Bennett, R. Borgen, K. Havelund, M. Ingham, and D. Wagner, “Prototyping a domain-specific language for monitor and control systems,” J. Aerosp. Comput., Inf., Commun., vol. 7, pp. 338–364, Nov. 2010. [17] D. C. Schmidt, “Model-driven engineering,” IEEE Computer, vol. 39, no. 2, pp. 25–31, Feb. 2006. [18] P. Arpaia, L. Bottura, V. Inglese, and G. Spiezia, “On-field validation of the new platform for magnetic measurements at CERN,” Measurement, vol. 42, no. 1, pp. 97–106, Jan. 2009. [19] M. Fowler, Domain Specific Languages, 1st ed. Reading, MA: AddisonWesley, Oct. 2010. [20] M. Jimenez, F. Rosique, P. Sanchez, B. Alvarez, and A. Iborra, “Habitation: A domain-specific language for home automation,” IEEE Softw., vol. 26, no. 4, pp. 30–38, Jul./Aug. 2009. [21] P. Hudak, “Modular domain specific languages and tools,” in Proc. 5h Int. Conf. Softw. Reuse, Jun. 1998, pp. 134–142. [22] D. Steinberg, F. Budinsky, M. Paternostro, and E. Merks, EMF: Eclipse Modeling Framework, 2nd ed. Reading, MA: Addison-Wesley, Dec. 2008. [23] D. G. Kourie, D. Fick, and B. W. Watson, “Virtual machine framework for constructing domain-specific languages,” IET Softw., vol. 3, no. 1, pp. 1–13, Feb. 2009. [24] R. C. Gronback, Eclipse Modeling Project: A Domain-Specific Language (DSL) Toolkit., 1st ed. Reading, MA: Addison-Wesley, Mar. 2009. [25] M. Fowler, “A pedagogical framework for domain-specific languages,” IEEE Softw., vol. 26, no. 4, pp. 13–14, Jul./Aug. 2009. [26] A. A. Dib, L. Feraud, I. Ober, and C. Percebois, “Towards a rigorous framework for dealing with domain specific language families,” in Proc. ICTTA Conf., Apr. 2008, pp. 1–6. [27] G. Muller, J. L. Lawall, S. Thibault, and R. E. Voel Jensen, “A domainspecific language approach to programmable networks,” IEEE Trans. Syst., Man, Cybern. C, Appl. Rev., vol. 33, no. 3, pp. 370–381, Aug. 2003. [28] P. Arpaia, M. Buzio, L. Fiscarelli, V. Inglese, G. La Commara, and L. Walckiers, “Measurement-domain specific language for magnetic test specifications at CERN,” in Proc. IEEE Instrum. Meas. Technol. Conf., May 2009, pp. 1716–1720. [29] D. Spinellis, “Notable design patterns for domain-specific languages,” J. Syst. Softw., vol. 56, no. 1, pp. 91–99, Feb. 2001. [30] J. Bosch and G. Hedin, “Workshop compiler techniques for application domain languages and extensible language models,” Lund Univ., Lund, Sweden, Tech. Rep. 96–173, Apr. 1996. [31] N. P. Chapman, LR Parsing: Theory and Practice, 1st ed. Cambridge, U.K.: Cambridge Univ. Press, Jan. 1988.
3766
IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 60, NO. 12, DECEMBER 2011
[32] OMG Mission Statement, Jan. 2011. [Online]. Available: http://www. omg.org/gettingstarted/gettingstartedindex.htm [33] P. Arpaia, L. Bottura, M. Buzio, D. Della Ratta, L. Deniau, V. Inglese, G. Spiezia, S. Tiso, and L. Walckiers, “A software framework for flexible magnetic measurements at CERN,” in Proc. IEEE Instrum. Meas. Technol. Conf., May 2007, pp. 1–4. [34] V. Inglese, “A flexible framework for magnetic measurements,” Ph.D. dissertation, Dept. Elect. Eng., Univ. degli Studi di Napoli Federico II, Naples, Italy, Nov. 2009. [35] JavaCC is a parser/scanner generator, Jan. 2011. [Online]. Available: http://java.net/projects/javacc/ [36] T. Parr, Language Implementation Patterns: Create Your Own DomainSpecific and General Programming Languages, 1st ed. Raleigh, NC: Pragmatic Bookshelf, Dec. 2009. [37] P. Arpaia, L. Fiscarelli, and G. La Commara, “Advanced user interface generation in the software framework for magnetic measurements at CERN,” Metrol. Meas. Syst., vol. 17, no. 1, pp. 27–38, Feb. 2010. [38] P. Arpaia, M. Buzio, L. Bottura, O. Dunkel, L. Fiscarelli, J. Garcia Perez, G. Montenero, E. Todesco, and L. Walckiers, “Measurement and scaling laws of the sextupolar component in the LHC dipole magnets,” in Proc. 1st IPAC, May 2010, pp. 23–28. [39] P. Arpaia, A. Masi, and G. Spiezia, “Digital integrator for fast accurate measurement of magnetic flux by rotating coils,” IEEE Trans. Instrum. Meas., vol. 56, no. 2, pp. 216–220, Apr. 2007. [40] L. Bottura, L. Walckiers, and R. Wolf, “Field errors decay and ‘snapback’ in LHC model dipoles,” IEEE Trans. Appl. Supercond., vol. 7, no. 2, pp. 602–605, Jun. 1997. [41] P. Arpaia, M. Buzio, L. Fiscarelli, G. Montenero, and L. Walckiers, “Highperformance permeability measurement: A case study at CERN,” in Proc. Int. Instrum. Meas. Technol. Conf., May 3–6, 2010, pp. 58–61.
Pasquale Arpaia was born in Napoli, Italy, on February 2, 1961. He received the M.D. and Ph.D. degrees in electrical engineering with the University of Napoli Federico II, Naples, Italy. He was a member of the Scientific and Administration Council of the new thematic University of Science and Technology, University of Napoli Federico II. In 2001, he was an Associate Professor with the University of Sannio. Since August 2005, he has been a Project Associate for the Large Hadron Collider with the European Organization for Nuclear Research (CERN), Gen, Switzerland. He was a Consultant on European Union (EU) IV Framework Program “Standard Measurement and Testing” and an Evaluator for EU International Association projects. He was responsible with Harald Schumny for the Promoting Committee of the European Project on Analog-to-digital-conversion (ADC)-based device Standardization (EUPAS) Project of the International Measurement Confederation (IMEKO) Technical Committee (TC) 4 “A/D and D/A Metrology” Working Group and was a Voting Member with the IEEE International Symposium on Integrated Management TC-10 "Waveform Measurement and Analysis" and of the International Electrotechnical Commission TC-47. His main research interests include digital instrumentation and software frameworks for magnetic measurements in particle accelerators; evolutionary diagnostics; ADC modeling, testing, and standardization; measurement systems on geographic networks; and statisticalbased characterization of measurement systems. In these fields, he published more than 150 scientific papers in journals and national and international conference proceedings. Dr. Arpaia was an Associate Editor for the Subject Areas "Quality and Statistical Methods" and “Test” of the IEEE T RANSACTIONS ON E LECTRON ICS PACKAGING AND M ANUFACTURING . He is an Editor of the Subject Area “Digital Instruments Standardization” for the Elsevier Journal Computer Standards and Interfaces. He organized several international meetings in the field of electronic measurements and European cooperation.
Lucio Fiscarelli was born in Benevento, Italy, in June 1979. He received the M.D. degree in telecommunication engineering from the University of Sannio, Benevento, in 2008, where he is currently working toward the Ph.D. degree with the Department of Engineering. From June to October 2008, his thesis on the development of the flexible framework for magnetic measurements was carried out in collaboration with the Department of Accelerator Technology, European Organization for Nuclear Research (CERN), Geneva, Switzerland. He is currently developing his research activities with the Magnets, Superconductors and Cryostats Group, Technology Department, CERN. His main research interests include software-based measurement systems and magnetic measurements on particle accelerators.
Giuseppe La Commara was born in Naples, Italy, on September 14, 1971. He received the M.D. degree in software engineering from the University of Naples Federico II, Naples, Italy. From 1999 to 2005, he worked on several European research projects with Tecnoret Research Centre. In 2005, he began a scientific collaboration with the University of Sannio, Benevento, Italy. From 2007 to 2009, he also was an unpaid Associate with the Large Hadron Collider, European Organization for Nuclear Research (CERN), Geneva, Switzerland. His main research interests include software frameworks for magnetic measurements in particle accelerators, graphical-interface automatic generation, domain-specific language, and model-driven engineering.
Carlo Petrone was born in Benevento, Italy, in November 1977. He received the M.D. degree in telecommunication engineering from the University of Sannio, Benevento, Italy, in 2009, with the Magnets, Superconductors and Cryostats Group (MSC), Technology (TE) Department, European Organization for Nuclear Research (CERN), Geneva, Switzerland. He is currently working toward the Ph.D. degree with the Magnets, Superconductors and Cryostats Group, Technology Department, CERN. His thesis dealt with advanced software tools for magnetic measurement systems. His research interests include information technologies and innovative magnetic measurements.
