Taking a look into the field of image processing for surface analysis, one will notice on the one hand a set of tools for the imaging characterisation of solids on various scales in the microscopic and submicroscopic range. Many of these methods were developed during the recent years and evolved into commercially available instruments, some are also available in a 3-dimensional variant. These methods offer different and in many cases complementary types of information on the object under investigation. Unfortunately, within the software packages offered for these commercial instruments there is hardly any image processing software available. On the other hand there is strong support by image- and signal-processing techniques starting from restoration algorithms up to sophisticated analysis tools for the analysis of measured data (e.g. deconvolution of images using maximum entropy, [Böhmig 1995b]). This is partly due to the exponential increase in available processing power for the same amount of money over the last decades and partly because many algorithms perfectioned in the field of aerial image processing or medical imaging have been adapted to surface science. However, the proprietary data processing software provided by the vendors of the analytical instruments generally is too limited to offer the high flexibility required within a scientific environment.
Commercially available surface analysis instruments are usually equipped with some basic image processing software. Leading edge software for digital image processing is however developed in fields like computer vision, aerial imaging and medical imaging etc.. In order to make use of those developments, an easy method of data exchange between and general purpose working environments is required and attracts increased interest in the scientific community.
The VAMAS Project (Versailles Project on Advanced Materials and Standards) was set up at the Economic Summit of Versailles in June, 1982 (C.J. Powell et.al. [Powell 1986, 1990]). A number of technical working parties have been organised, one of which is Surface Chemical Analysis chaired by Dr. M.P. Seah [Seah 1992, 1989, 1990, 1993]. The Surface Chemical Analysis Technical Working Party has 31 projects. Members of the VAMAS community working for the projects nos. 10 "Development of a standard data transfer format" (W.A. Dench et.al. [Dench 1988a, 1988b]) and for the projects nos. 29,30 "Development of a file format translation system" and "Development of a common data processing system for AES and XPS" (K. Yoshihara et.al. [Yoshihara 1992, 1994]) are working in the field of interchangeability of surface analytical data.
Since spring 92 a new journal "Surface Science Spectra" is produced by the American Institute of Physics, publishing data of various surface analytical methods in standardized form (C.E. Bryson et al. [Bryson 1992]). A forth example for this development are the presentations by M.P. Seah, C.J. Powell, S. Tougaard, A. Jablonski and M. Yoshitake on the data interchangeability of Auger and XPS-spectra produced by different instruments and a proposed intercalibration procedure as well as a "Cross Section Database". The lectures were given on the ECASIA in Montreux (Switzerland) in October 1995. All these attempts on data interchangeability are only concerning spectra and hardly images.
From my point of view for several different analytical methods being applied to the same sample, a more general approach is needed in order to combine data of various instruments in a common data evaluation and reduction procedure. An as complete as possible documentation of the measurements performed has to be an integral part of a data management system in multi-method analysis. If one conceives a measurement as an interaction of an analytical instrument with a sample, the state of the instrument, the state of the sample and a set of variable parameters have to be recorded in order to document this process. Parameters set by the operator as the primary energy, etc. and more or less environmental parameters like the background pressure and the composition of the residual gas in the analysis chamber can be involved. As the state of a sample is influenced by all manipulations of that sample (treatments and measurements), it can only be reasonably documented in form of a sample history. Even if this is less obvious, instruments also change over time, e.g. the state of the vacuum equipment or due to the exchange of components, which leads to the necessity of an instrument description in chronological order. In this case, however, a dated state of the instrument seems to suffice as a documentation for a measurement series and in consequence also for single measurements. Additionally, the variable parameters have to be recorded. This descriptive information together with the raw data of single measurements (spectra, maps) or measurement series (e.g. depth profiles) obtained will be needed for later evaluation procedures.
For practical reasons, all information associated with one series of measurements i.e. raw data and descriptive information of 1 to n single measurements should be packed physically together in one file for transport. This seems to be the best way to avoid problems with different filesystems with varying limitations on different computers. On the other hand, it is desirable to pack raw data, which can be very voluminous, as densely as possible in binary format while maintaining the flexibility of human readability for the descriptive information.
In order to satisfy these quite different requirements, the idea of a very flexible data management system for multi-method analysis based on a hierarchical data format was born. As only a standardized data exchange format can guarantee the independence of proprietary measurement systems, the software package MAXMIND [Brandl 1995, 1996a, 1996b] was developed, which is based on public domain software products. The software is highly flexible, extensible and can be adapted to most analytical instruments without modification of existing control software and can be used for the transfer, archiving and editing of surface analytical data.
Data collection
The data describing the experiment are split into measurement parameter data (pressure, temperature, primary energy ...), instrument history (geometry, analyzer, detector...) and the state of the sample stored in the sample history (initial state, preparation, pointers to actual measurement data,...). All three types of data are implemented as lists of parameters. In the format of this proposal all parameters are attributed. Attributes determine, where the parameter value come from, if the input of the value is automatic or interactive, whether the parameter is necessary, if the parameter value can be inherited, whether the range of the value is controlled and the type of the parameter value. Every listed parameter is specified by its name, attributes, value and physical unit (e.g. cm, eV,...). The lists of parameters are structured into chapters and can be extended in a simple way, if there is demand for a new parameter. These above mentioned features are the two main aims of the format: high data transparency and a high degree of flexibility.
There are lists of parameters (data dictionaries) for the different analytical techniques Auger Electron Spectroscopy (AES), Scanning Auger Microscopy (SAM), X-Ray Photoelectron Spectroscopy (XPS), Secondary Ion Mass Spectrometry (SIMS), Scanning Tunnelling Microscopy (STM) and Atomic Force Microscopy (AFM). The lists are influenced by the work of W.A. Dench and M.P. Seah et.al. and the VAMAS community [Dench 1988a], C.E. Bryson et.al. [Bryson 1992], H.J. Grabke et.al. [Grabke 1983], L.C. Feldman et.al. [Feldman 1986] and M. Puchhammer [Puchhammer 1987].
Image processing
In general the scientific problems of this approach are accompanied by problems in the field of data processing and data organisation. For the exchange of data and control information between computers of different kinds controlling various instruments, a standardized data format is needed. Once the data have been transported by these mechanisms and are all available on a single computer system in a compatible format, geometric transformations have to be applied in order to compensate for different distortions produced by different instruments. After these initial processing steps have been successfully applied, the main evaluation process can be entered (e.g. image fusion, principal components analysis, segmentation, statistical analysis...). A final processing step is the rendering of results in suitable form.
Whereas commercial and public domain software for standard image processing operations is offered by a number of institutions, software for processing steps specific to surface analysis is not generally available. The task of the image processing proposed can be thought as a flow-chart with file inputs from different measurement devices, boxes representing processing modules and output connections. A multi-method data processing system requires that a flow-chart performing a specific operation such as a classification has to be set up only once to process images or spectra from different measurement devices with different data formats. Hence, classifying a SAM image and an EPMA image should not require tuning of parameters like image size in um, image format, data type, number of bands etc. Parameters having the same meaning for all different data sources are accessible in a consistent manner via a label and are used to dynamically control the flow of execution. Parameters specific to only one or a subset of supported sources can be processed in a similar way.
Integrated processing system
Beside the data management system MAXMIND the integrated processing system consists of a few processing units. The first component is an interface from MAXMIND to either MATLAB or KHOROS, which both are well known data analysis environments in the surface analysis and image processing community. Both interfaces can be controlled with a graphical user interface (GUI) or by command line. Image and spectrum data together with a selection of descriptive information can be extracted from the MAXMINDs HDF-files (see chapter 4.1.1.) as well as the contents and internal structure of HDF-files (Vsets) can be viewed. An automatic extraction of series of spectra or images stored in an HDF-file is possible. Interfaces can be integrated in scripts (MATLAB) or workspaces (KHOROS) to automate repetitive evaluation tasks.
The altogether third component of the integrated processing system is a source-independent file format based on HDF, which allows to store all data relevant for analysis together with the actual raw data. The idea of introducing this new storage layer is to guarantee the independence of the data structure from the - possibly changing - formats of the measurement devices.
The link between HDF on the one hand and KHOROS or MATLAB on the other hand is managed by a module allowing an automatic extraction of a selection of tags or data elements from an HDF file or vice versa. It dynamically builds a parameter mask which pops up on the screen and offers the user the possibility to assign KHOROS or MATLAB-variables to data elements in the HDF file. If elements are not available in a certain HDF file they are simply not filled in. Thus, if the relevant elements are available of various analytical tools, images can be processed by a single flow-chart without having to worry about data conversion problems.
Cost-benefit analysis
A detailed cost-benefit analysis of the software system MAXMIND is difficult to establish at this point. The costs are largely composed of a one time installation effort and of the effort required to apply the software to individual analyses. Whereas the one time effort is specific for this software, one considers the effort of applying the system as equivalent to a good manual documentation of sample preparation steps and measurements. If large series of similar samples or samples investigated by a number of analytical methods are considered, the effort of machine based documentation should be less then that of maintaining a decent laboratory journal due to reuse of information.
The benefits of the system are mainly the interchangeability of data and the standardized documentation. This helps to make the results of instruments comparable, to use the same data reduction software for data from more than one instrument and to avoid duplicate work due to incomplete documentation. It is obvious from the abovesaid, that analytical laboratories handling samples on a variety of instruments will initially have the biggest benefit from the new software. The scientific community will in the long run take advantage from the easier exchange of data and software.
Input radiation Electrons Ions Neutrals Photons/X-rays Electrons AES INS UPS APS XPS EELS HREELS Radi- ation lons ESD ISS FABMS LAMMA detected SlMS LlMA Neutrals NICISS SNMS Photons/ EPMA PIXE X-rays
Table 2.1 Overview of the principal surface analysis techniques [Briggs 1990]
Ek = h[[nu]] -EB -e[[phi]] (2.1)
where Ek = kinetic energy of ejected photoelectron
h[[nu]] = energy of
X-ray photon
EB = binding energy of core level
e[[phi]] = work
function term
that the line width of Ek will depend on the line width of h[[nu]], since that of the core level is narrow and e[[phi]] is constant for a sample. Now in XPS, chemical information is extracted by detailed analysis of individual elemental spectra, including resolution of contributions from the various chemical states present, from which it follows that the best energy resolution should be used compatible with the signal-to-noise ratio in the particular spectrum. Thus in XPS the two materials used universally as anodes in soft X-ray sources are magnesium and aluminium (Mg K[[alpha]], Al K[[alpha]]). In general X-rays are generated in a material by bombardment with electrons of sufficient energy (energy of the incident electrons up to 10 keV).
In both XPS and AES the heart of the technique is the measurement of an electron energy spectrum. Such an analysis is performed by an electron energy analyzer, often also called a spectrometer.
Although the single-stage cylindrical mirror analyzer (CMA) has been so successful for AES it is not suitable for XPS since it is necessary for the latter to have both good energy resolution and good absolute energy calibration. Good energy resolution can be obtained by retarding electrons to a constant pass energy as they enter the analyzer. In the CMA this retardation is performed by two hemispherical meshes centred on the source area of the sample with the first mesh at sample potential, usually ground and the second at the potential of the inner cylinder of the CMA. In other words in this version the inner cylinder is not grounded as for AES.
The entrance slit of a CMA is usually the illuminated spot on the sample. Therefore a change in the sample - analyzer distance changes the energy calibration. This problem can be partially resolved by adding a second CMA in series with the first one, forming a double-pass CMA. The length of the second CMA is defined by two orifices and is therefore fixed. The arrangement is shown in Figure 2.1.
Fig. 2.1: Diagram of a double-pass CMA, used for both XPS and AES. Electrons are retarded to a constant pass energy for XPS via two spherical grids at the entrance to the first stage, centred on the source area on the sample. The exit aperture of the first stage constitutes the entrance aperture to the second stage. The entrance and exit apertures to the second stage can be changed remotely through an external rotary motion drive. For AES the retard grids and the inner cylinder are grounded [Puchhammer 1987].
The transmission, and hence the energy resolution, of the second stage can be altered by changing the sizes of the entrance and exit slits by remote control from outside the analyzer. For XPS, however, the slits must be kept as large as possible so as to maintain luminosity .
The second analyzer discussed is the concentric hemispherical analyzer (CHA), which is probably the most suitable type of analyzer for XPS. The basic form of a CHA is shown in Figure 2.2 consisting of two hemispheres of radii R1 (inner) and R2 (outer), concentrically positioned, and the potentials -V1 and -V2 being applied to the inner and outer hemispheres respectively.
Fig. 2.2: Schematic cross-section of a concentric hemispherical analyzer (CHA). Two hemispheres or radii R1 (inner) and R2 (outer) are positioned concentrically. R0 is the radius of the median equipotential surface. Potentials -V1 and -V2 are applied to the inner and outer spheres respectively, with V2 greater than V1. The source S is located in the entrance slit of width W1 and the focus F in the exit slit of width W2. The divergence of an electron entering the analyzer from the ideal tangential path is d[[alpha]] [Briggs 1990].
Electrons of the correct energy E0, injected tangentially at the source S, are all focused at the focus F, for the complete hemisphere with radius R0. Electrons being injected at an angle d[[alpha]] to the correct tangential direction and with an energy [[Delta]]E different from the correct energy E0 are analyzed with the base energy resolution [[Delta]]Eb / E depending on the square of the angular spread. For the CMA the energy resolution goes by the cube of the angular spread.
Two types of electron sources are used in AES, the thermionic and the field emission, with the former being much more common. In thermionic emission a material is heated to a temperature high enough to give some electrons sufficient energy to escape over the work function barrier at the surface into the vacuum. The higher the temperature the greater the thermionic current, which is governed by the Richardson equation [Briggs 1990]
J = A(1-r) T2 exp (-e[[phi]] / kT ) A/cm2
(2.2)
where J = current density
A = Richardson constant, whose ideal value is
120 A/(cm2 deg2), but which varies with material
r = zero-field electron reflection coefficient
T = absolute temperature
e[[phi]] = work function
Field emission operates by reduction of the height of the work function barrier through application of a high electrostatic field, so that even at room temperature electrons can escape from the material. They escape by tunnelling through the barrier, a mechanism that has a negligibly low probability under normal field-free conditions but can be made highly probable by the application of a sufficiently high field. The field is enhanced to the necessary strength by shaping the emitter into the form of a sharp point whose apex radius is of the order of 50 nm. A voltage of many kilovolts is then applied between the point and an extractor so that the field strength at the apex is some 10 V/nm. The field emitted electron current is governed by the Fowler-Nordheim expression [Briggs 1990]
J = ( 1.55 x 10 -6 E2 / e[[phi]]) exp [--6.86 x
107(e[[phi]])3/2 [[Theta]](x) / E] A/cm2
(2.3)
where J = current density
E = field strength
[[Theta]](x) =
Nordheim elliptic function, in which
x = 3.62 * 10 -4 E
1/2 / e[[phi]]
e[[phi]] = work function
Expression (2.3) shows that the current density is strongly dependent on the work function of the emitter, and it is therefore usual to prepare the emitter tip in such a way that a low work function plane is at the apex, e.g. by using a suitably oriented needle-like single crystal. Adsorption of residual gases from the vacuum will almost always modify the work function of a surface, so it is necessary not only to start with a clean emitting surface but to maintain it in that condition during operation, otherwise instability will result. Cleaning is accomplished by heating the tip to a high temperature briefly, while the maintenance of its clean state necessitates a particularly good level of UHV around it, i.e. 10 -11 mbar or better. The emitter material is always tungsten, since it can withstand both the high temperature treatment and the high electrostatic field.
The main component of an AES is the electron energy analyzer, often called the spectrometer. The often used double-pass cylindrical mirror analyzer (CMA), which can be used for AES as well as for XPS is described in chapter 2.1. (X-Ray Photoelectron Spectroscopy).
S = (P / B -1) without dimension (2.4)
where S = concentration
P = peak signal
B = background signal.
This compensates in first order for topographic effects and for an analyzer acceptance varying over the area of the image. Thus a scanning Auger image normally contains two bands, peak and background. Multi element maps contain several pairs of bands.
For further details about source and analyzer take a look to chapter 2.1.2. (Auger Electron Spectroscopy).
Figure 2.3 shows the principle of operation of a scanning tunnelling microscope, which is based on the so-called tunnelling current. On can consider two conducting electrodes separated by some isolator, that forms a barrier for the electrons inside the electrodes. If the barrier is thin enough, electrons start to travel trough the barrier by a quantum-mechanical mechanism called tunnelling. In an STM, this barrier is a vacuum gap of approximately one nanometer. The tunnelling electrons constitute a current which depends exponentially on the distance between the electrodes [Leemput 1992].
When a sharp tip approaches a conducting surface at a distance of approximately one nanometer, the tunnelling current starts to flow. The tip is mounted on a piezoelectric tube, which allows tiny movements by applying voltages to its electrodes. Thereby, the electronics of the STM system controls the tip position in such a way that the tunnelling current and, hence, the tip-surface distance is kept constant, while at the same time scanning a small area of the sample surface. This movement is recorded and can be displayed as an image of the surface topography. Under ideal circumstances, the individual atoms of a surface can be resolved and displayed.
It should be noted, however, that STM images not only display the geometric structure of the surface, but also depend on the electronic density of states of the sample, as well as on special tip-sample interaction mechanisms which are not fully understood yet.
Although the STM itself does not need vacuum to operate (it works in air as well as under liquids), ultrahigh vacuum is required to avoid contamination of the samples from the surrounding medium.
Fig. 2.3: Principle of operation of a scanning tunnelling microscope (Repro-duced from 'http://www.iap.tuwien.ac.at/www/surface/STM_Gallery/' by permission of M. Schmid)
A problem in investigating metal surfaces is the fact that these surfaces appear very flat to an STM, i.e., the apparent height of individual atoms (corrugation) is 1/100 to 1/10 of an atomic diameter. Therefore, for resolving individual atoms the distance between the tip and the sample must be kept constant within 1/100 of an atomic diameter or better (approx. 0.002 nm). This demands not only very high rigidity of the STM itself, but the STM must be also efficiently decoupled from environmental vibrations.
A sharp tip mounted on a soft lever is scanned across the sample surface by means of piezoelectric translators, while the tip is in contact with the surface. The force acting on the tip changes according to the sample topography resulting in a varying deflection of the lever (see scheme in Fig. 2.4), which in commercial instruments is measured by means of laser beam deflection off a micro fabricated cantilever and subsequent detection with a double segment photo diode. Fig. 2.5 shows a schematic view of one frequently used detection concept [Digital Instr.].
Fig. 2.4: Principle of AFM. The sample symbolised by the white and black circles is scanned by means of a piezoelectric translator.
Today cantilevers with extremely low force constants of less than 1/10 N/m and resonance frequencies of more than 100 kHz can be produced, which allow imaging with forces in the nN and sub-nN range. These forces are about 10.000 to 100.000 times lower than the force of gravity introduced by a fly (1 mg) sitting on a surface. But high local pressures (MPa up to GPa) are encountered, which may cause artefacts during measurement especially on soft systems (e.g. biological samples).
Fig. 2.5: Schematic view of the deflection sensing system as used in the NanoScope III AFM (Digital Instruments, Santa Barbara, Calif.). The deflection of the triangular shaped cantilever is amplified by a laser beam focused on top of the cantilever and reflected towards a split photo diode detector. [Friedbacher 1994]
In AFM the tip is always touching the sample surface, which we call the contact mode. As a consequence there is always an interatomic repulsive force at the contact area due to penetration of the electronic shells of the tip and substrate atoms. In addition to this short range force also long range forces (e.g. coulomb forces between charges, dipole-dipole-interactions, polarisation forces, van der Waals dispersion forces, capillary forces due to adsorbate films between tip and substrate), which can be attractive or repulsive are encountered (Fig. 2.6). Although both types of forces contribute to the total force acting on the cantilever, only the varying repulsive interatomic force allows high resolution imaging of surfaces. Since long range attractive forces pull the tip towards the sample surface they give rise to an increase in the local repulsive force which can deteriorate the experimental conditions. Thus it is important to minimize those long range forces in order to achieve very low repulsive forces (nano-Newton and less) in the contact area between tip and sample. This is especially important when looking at soft materials, which can be deformed or destroyed easily by the load of the tip.
Fig. 2.6: Schematic view of forces encountered when the tip touches the sample surface. The circles symbolize the sample atoms and the tip atoms respectively.
Besides AFM there are also other scanning force microscopy techniques
(e.g.
electrical force microscopy, magnetic force microscopy, van der Waals force
microscopy), which operate in the non-contact mode and make use of long range
forces mentioned above. High local contact forces are eliminated in these
techniques, but atomic resolution cannot be achieved due to the high separation
(up to several nanometers) between tip and sample surface.
The interaction between tip and sample can be described by force-distance curves. As can be seen in Fig. 2.7 the force changes, when the sample surface approaches the tip. At large separations there is no interaction and the observed force is zero (straight line between 1 and 2, if we assume that there are no electrostatic charging forces). At position 2 the tip jumps into contact due to attractive van der Waals interaction. As the sample is further moved towards the tip the total force acting on the cantilever becomes repulsive. When the sample is retracted again, the force is reduced along the line from position 3 to 4. Below the zero force line in the diagram the net force acting on the cantilever becomes attractive, because the tip is held at the surface due to adhesion.
Fig. 2.7: Force-distance curve depicting the interaction of the AFM tip with the sample surface. The operation range of the AFM is between 3 and 4.
In 4 the adhesion force and the cantilever load are just balanced and the tip flips off the surface when further retracting the sample. For AFM measurements the force can be set along the curve between position 3 and 4, preferably close to 4 in order to minimize the contact force. The value of the pull-off force can be reduced significantly by imaging under liquids due to elimination of capillary forces, which pull the tip towards the sample. For a general overview on force interactions see [Israelachvili 1991].
Analytical Potential of AFM:
The following basic properties of AFM are of significant interest for surface analysis:
* imaging capabilities from the micrometer down to the atomic scale
* images contain direct depth information (useful for roughness
measurements)
* both conductors and insulators can be imaged readily (no coating necessary)
* in-situ measurements under liquids and in air allow direct observation of surface processes
AFM images - in many cases with atomic resolution - have been obtained for a variety of metals, semiconductors and insulators including graphite and gold [Manne 1990, 1991, Goss 1993].
The emission of secondary ions during ion bombardment of solid surfaces by a beam of ions is the result of a "two step process". At first, the impact of energetic (1-20 keV) primary ions (typically noble gas, Cs+ or 02+) provides, through a collision cascade, the momentum for the sputtering of surface atoms. It is of analytical importance that more than 90% of the sputtered atoms originate in the outermost atomic layer. The actual collisions which cause surface atoms to eject can be rather low in energy compared to the initial beam energy. The energy distribution of these particles is therefore peaked at relatively low energies (~ 2-10 eV). In that case the charge state of the sputtered atom is determined by the electron exchange between the atom (or ion) and the surface. In general, the charge state of the sputtered atom is not related to the charge of the incoming primary ion. The ionization phenomenon is usually caused by the charge exchange between the valence levels of the sputtered atom or ion and those of the solid [Yu 1986]. In the sputtered "cloud" of particles only a small fraction is ionised - the so-called secondary ions (SI). In SIMS, these secondary ions are analysed in a mass spectrometer by measuring the mass to charge ratio (m/e). Figure 2.8 shows the basic principle of sputtering, indicating the collision of the primary particles with a solid surface and the emission of secondary particles (neutral and ionised atoms and molecules, respectively).
During the sputtering process primary ions are implanted into the sample surface leading to a zone of changed composition and structure ("altered layer"). The depth of this zone is about the double mean projected range (Rp) of the primary ions. After sputtering of a surface layer 2-3 Rp in thickness an equilibrium between implantation and erosion is achieved [Grasserbauer 1984]. Then the measurement is performed by periodically counting the secondary ion intensity Ii+/- of an element i detected in a SIMS equipment (counts/s).
Fig. 2.8: Basic principle of sputtering, indicating the variety of secondary particles emitted.
The sensitivity of the technique is related to the mechanism of secondary ion formation which is dictated by the ionization probability of element i. It is well established that the presence of electronegative atoms (e.g. oxygen) on the sample surface greatly increases the formation of positive secondary ions ("oxygen enhancement effect"). On the other hand the presence of electropositive atoms (e.g. caesium) on a sample surface can greatly increase negative secondary ion yields by three to four orders of magnitude ("Cs induced enhancement effect"). Thus reactive species like oxygen and caesium are utilised as primary projectiles to increase sensitivity. The detection efficiency has been termed "useful yield" and is the product of the ionization efficiency and the mass spectrometer transmission .
The mass and energy filtered secondary ion current Ij+ can be measured as a function of time (depth profile), as a function of mass (mass spectrum), as a function of energy (energy spectrum) or in a mode providing element specific images. Ion images can be recorded almost continuously in an image depth profile to provide three dimensional pictures.
An as complete as possible documentation of the measurements performed has to be an integral part of a data management system in multi-method analysis. The software package MAXMIND is based on the concept of a measurement being an interaction between an analytical instrument and a sample. After measurements performed, documentation concerning the state of instrument and sample as well as experimental parameters are packed together with raw data into a single file. One has to record in detail the state of the instrument at the point of the measurement, the state of the sample starting with the manufacturing up to the point of the measurement and a set of variable parameters in order to document this process. Parameters set by the operator as the primary energy, beam intensity etc. and more or less environmental parameters like the background pressure and the composition of the residual gas in the analysis chamber can be involved.
As the state of a sample is influenced by all manipulations of that sample (treatments and measurements), it can only be reasonably documented in form of a sample history. Even if this is less obvious, also instruments change over time, e.g. the state of the vacuum equipment or due to the exchange of components, which lead to the necessity of a description of an instrument in chronological order, which is denoted instrument history. In this case however, a dated state of the instrument is firstly required for a sufficient documentation and secondly as default record for a measurement series and in consequence also for single measurements. The complete state of the sample (sample history) is used for documentation and can optional be used for inheritance of specific parameter values. Additionally, the variable parameters have to be recorded in order to complete the descriptive information. The raw data of single measurements (spectra, maps) or measurement series (depth profiles...) together with the whole descriptive information obtained will be needed for later evaluation procedures.
For practical reasons, all information associated with one series of measurements i.e. raw data and descriptive information of 1 to n single measurements should be packed physically together in one file for transport. However the scientist may decide on that point how many single measurements to take into one physically file, which may contain a measurement series partly or entirely. By the way, talking about multi-method analysis, measurement series consisting of images and spectra of various analytical tools are also conceivable at that point. In this case the descriptive information includes one sample history, one instrument description per analytical instrument, one measurement series description, one description of every single measurement and the appropriate raw data. The decision to create a few not too voluminous files seems to be the best way to avoid problems with different filesystems and varying limitations on different computers. In any way it is desirable to pack raw data, which can be more or less voluminous, as densely as possible in binary format while maintaining the flexibility of human readability for the descriptive information.
In order to satisfy these quite different requirements, a very flexible data management system MAXMIND based on HDF (Hierarchical Data Format [HDF 1993a]) for multi-method surface analysis was developed. As shown in figure 3.1 data describing the experiment coming from different sources like the instrument history (instrument geometry, analyzer resolution, detector dead time...) and the state of the sample stored in the sample history (initial state, all sorts of treatments, pointers to measured data...). Together with the raw data (images and spectra) the measurement parameter data (primary energy, intensity, measurement energies...) are extracted by invoking a conversion interface. The user input (measurement series number, measurement number, date, time, ...) additionally completes the data collection of the MAXMIND input.
The three types of data i.e. the measurement parameters, the instrument history and the sample history are implemented as lists of parameters. Attributes determine where these parameters come from, if the input is automatic or interactive, whether the parameter is necessary, if its value can be inherited, whether the range of value is checked, and the data type of the parameter value. Every listed parameter is specified by its name, attributes, physical unit, value and optional comment. The lists of parameters are structured into chapters and can be extended in a simple way, if there is demand for a new parameter. The software is highly flexible and extensible, with the possibility of adapting to most analytical tools without modification of existing control software.
Fig. 3.1: Overview of MAXMINDs data flow including the schematic connections to existing software of analytical tools and data analysis [Dreschler 1996]
What are the aims of MAXMIND ?
* Strict separation of the software design and the development of data dictionaries (sets of parameters for various methods) and extensible formal grammar system of attributes and dictionary sections (subsections).
* A new approach for an open and extensible data management system based on public domain software products (lex, yacc, HDF, KHOROS)
* One standardized data exchange format for a variety of analytical techniques such as: AES, SAM, XPS, STM, AFM, SIMS in order to enable the use of common data evaluation and reduction procedures
* Storage of an as complete as possible documentation of the measurement together with the raw data in hierarchical data files (HDF Vsets)
* Implementation of the necessary software tools to handle this standard for a variety of operating systems (DIGITAL-UNIX, ULTRIX, HPUX, LINUX and VAX/VMS)
* Development and implementation of data base like search operations
Binary data gathered manually or automatically in the course of the measurements can be divided in raw data of images and spectra and protocol information concerning the measurement. If one take a look at the protocol information, one will realize that a lot of parameters are constant, for a number of single measurements, measurements concerning one sample or one analytical instrument, and only a few change. At this point a measurement series description was introduced in order to avoid the storage of the same unchanged parameter values within one file for twenty times or more (e.g. a few parameters in the description a depth profile).
Based on the concept of a measurement being an interaction between an analytical instrument and a sample, the idea of a sample history and an instrument history was born, and it was finally decided to split data gathered in the course of the measurements into five different groups (see table 3.1)
1. Spectrum or map (image) raw data (single measurements or measurement series e.g. depth profiles)
2. Measurement parameter data (pressure, temperature, primary energy ...)
3. Instrument history (geometry, analyzer, detector...)
4. Sample history (initial state, preparation, pointers to actual measurement data,...)
5. Interactive user input (measurement number, author, comments,
HDF-filename)
Table 3.1: Various data groups describing a measurement
As can be seen in figure 3.2, spectrum or map raw data, measurement parameter data, instrument history and sample history can be archived on different computers and different storage media. Together with the raw data of measured spectra and maps or images, which we denote spectra and map raw data, the analyst also gets information about temperature, pressure, primary energy, etc. called the measurement parameters raw data. In many cases, these two groups of data are stored as separate files within the filesystem of the experiment computer. The instrument history describes a certain instrument (e.g. AES, SIMS, AFM,..) and should be stored on the computer controlling the respective instrument. The sample history lists up relevant events concerning the sample (e.g. in situ and ex situ treatments, measurements, etc.) and should locally be kept together with the sample itself (e.g. on a transportable storage medium such as a floppy-disc). Finally the user input is necessary for entering values or optional parameter comments, which have to
Fig. 3.2: The schematic data concept showing data transfer and different storage media for spectrum or map raw data, measurement parameter data, instrument history and sample history [Brandl 1995].
be stored in the final binary measurement file and which are not available in computer-readable form (e.g. automatically transferred from the measurement instrument). The data conversion-tool combines the spectra and image raw data in a binary form and all parameters associated with the measurements in ASCII form in one physical file (MAXMIND HDF-file).
Measurement parameters raw data are part of the measured raw data are a kind of "data source" for the conversion tool. Attributed forms, the measurement series description form and the measurement description form, control the conversion from the raw source to the description Vsets. These forms are implemented as lists of parameters and are structured into main chapters and subchapters. Every listed parameter is a data object and is specified by the parameter name, various attributes, physical unit and optionally defaulting value and comment. If there is demand for a new parameter the lists can be extended in a simple way.
Every parameter of the measurement (series) description Vset is described by the attributes inheritance, editor mode, necessity, working environment, control and data type. A formal grammar based on the attributes enables automatically parsing of the forms by lex (lexical analyzer) and yacc (yet another compiler compiler) [AT&T 1988a, 1988b, Herold 1992] programs (see chapter 5. Implementation). In table 3.2 all possible attributes are depicted. The few states of every attribute are summarized in groups. Every attribute have to be placed once in the parameter (line) after the parameter name in one of the few possible states. If there is demand for new attribute states or for new attributes, an extension of the yacc grammar is necessary.
For further details concerning the transfer from the measurement parameters (raw data) to the measurement series description Vset and the measurement description Vset (ASCII data Vsets within a binary HDF-file) see chapter 3.3..
Attribute 1: Inheritance
manual Parameter value is
entered by the scientist
raw(instrument) Parameter value
is extracted from the measurement parameter data by a binary data converter
(see chapter 4.1.4.)
default(,,) Parameter value is defaulted from
the previous measurement series description Vset or measurement description
Vset
inst(,,) Parameter value is extracted from an instrument
description Vset
sh(,,) Parameter value is extracted from a
sample history Vset
Attribute 2: Editor mode
visedit Parameter is visible
and editable
visual Parameter is only visible not editable
notvis Parameter is not visible
Attribute 3: Necessity
necess Parameter value is
necessary
unnec Parameter value is unnecessary
Attribute 4: Working environment
khoros Parameter is
visual in the chosen working environment (KHOROS, MATLAB..)
nokhoros Parameter is not visual
Attribute 5: Control
nocont Parameter value is not
controlled
minmax(Minimum;Maximum) Range of
parameter value is controlled
instminmax(Minimum;Maximum) Range of parameter value
is controlled by defaulting the limits from the instrument
description Vset
select(value1,value2,...)
Parameter value is selected from a list of values
Attribute 6: Data type
integer
real
string
boolean
Tab. 3.2: Possible attributes for inheritance, editor mode, necessity, working environment, control and data type of a parameter.
The instrument history is an ASCII-file, which describes a certain instrument (e.g. AES, XPS, STM,..). As mentioned above, each of these "source"-files for the dated state of a special instrument, which is denoted instrument description, consist of a list of parameters together with their 'data type' attributes, physical units, parameter values and optional parameter comments.
The instrument history starts with the initial state of the instrument or at the point of time the first description takes place. As table 3.3 shows, the history consists of sections and subsections. If there is a change of one component of the instrument e.g. the analyzer, the respective subsection is entered once more with new date, time, author, instrument and new values, physical units and parameter comments.
The attributed form for producing the instrument history consists of a list of parameters, the attribute 'data type', physical units and optional values and parameter comments (see table 3.3). Integer, real, string, boolean, pointer, rawpointer and descriptpointer are the few possible states of the attribute 'data type'. When the yacc program recognizes the 'data type' attribute with the states pointer, rawpointer and descriptpointer in the syntax of the form, a list of files is incorporated into the history. In that way it is possible to automatically fill in pointers indicating data files and especially HDF Vsets. Unlike to the measurement (series) description form, the instrument history form has necessarily no other attributes, because all input is manual, there is no inheritance, and values and necessity of parameters are not checked except for proper data type.
(a)
Instrument History of specific
instrument
Section_number Section_title
. Sub_section_number
Sub_section_title
. . Date:
. . Time:
. Author:
Analytical_Instrument:
Parameter attribute
'data type' [unit] value \*parameter comment*\
.
.
.
(b)
"type" - attributes (describing the parameter value):
integer
real
string
boolean
pointer list of files
rawpointer list of raw data files
descriptpointer list
of description Vsets
Table 3.3: System of sections and subsections of an instrument history (a) as well as a short explanation of attributes (b)
Hence, the actual state as well as any dated state of the instrument including all hardware components as heater, vacuum equipment, ion gun, etc. can be accessed via a viewing tool. Either the chronology of one chapter of the description or the whole instrument history can be displayed, as well as all history entries done by one author since a specific point of time. The redundancy in this concept should not lead to inconsistencies, as the subsections in the instrument history are only appended and never changed.
As can be seen in table 3.4 the instrument history consists of a number of main sections.
AES SIMS AFM 1. Instrument 2. 1. Instrument 2. 1. Instrument 2. Vacuum_equipment 3. Vacuum_equipment 3. Vacuum_equipment 3. Laser Source 4. Sample_holder Source 4. Sample_holder 4. Sample_holder 5. 5. Analyzer 6. Detector 5. Analyzer 6. Detector Cantilever 6. Detector 7. 7. Additonal_Ion_Gun 8. 7. Additonal_Ion_Gun 8. Additonal_Ion_Gun 8. Heater Heater Heater
Table 3.4: Main sections of the instrument history of AES, SIMS, and AFM in comparison
The formal description of quite various analytical tools e.g. AES, SIMS and STM (which belong to Electron-Spectroscopes, Ion-Methods and Scanning-Probe-Microscopes) leads to differences in the chapter structure of main chapters and subchapters (section 5 of AES and AFM: Analyzer - Cantilever). Subsections of various instruments having sometimes the same name but are describing a quite different mechanism. The subsection 1.2. in the instrument history of Electron-Spectroscopes (AES, SAM) "Instrument_geometry", which can be seen in table 3.5, describes the angle geometry between source, sample (sample holder), analyzer and detector. The graphical scheme of the instrument geometry of an AES instrument is depicted in Figure 3.3.
There is also a sort of instrument geometry in the case of Scanning-Probe-Microscopes (STM, AFM), concerning the angles between laser, prism, cantilever, mirror and the split of the photo diode detector. In comparison with Electron - Spectroscopes and Ion - Methods, where the angle geometry is of essential importance for measurement, these angles are of less influence for the measurement of Scanning-Probe-Microscopes (STM, AFM).
1.2. Instrument_geometry
Date: 1995-06-17
Time: 10:29:46
Author: Reichl
Analytical_instrument: Auger
Emission_angle
real [deg] 48 /*Theta(e) 48 +-3*/
Incident_angle real [deg] 45
/*Psi(i)*/
Source_to_analyzer_angle real [deg] 0 /*Theta(s)*/
Sample_normal_azimuthal_angle real [deg] 0 /*Phi(sp)*/
Sputter_source_incident_angle real [deg] 35 /*Psi(ig)*/
Sputter_source_polar_angle real [deg] 80 /*Theta(ig)*/
Sputter_source_azimuthal_angle real [deg] 60 /*Phi(ig)*/
Table 3.5: Showing subsection 1.2., the instrument geometry of an Auger instrument
Fig. 3.3: Graphical scheme of the instrument geometry of an AES instrument [Bryson 1992]
In the case of the sample history the data source is an editable ASCII-file, which lists relevant events concerning the sample, such as treatments and measurements. If the sample is analysed by several surface analytical instruments in different laboratories the sample history, as mentioned before, should be kept together with the sample itself (e.g. on a transportable storage-medium such as a floppy-disc) and should be updated after every measurement series. The first entry of this file is a detailed description of the initial state of the sample and conditions of manufacturing.
In the same way as the instrument history (see table 3.3), the sample history consists of sections and subsections. If ex situ treatments or in situ treatments "happens" to the sample the subsection describing the process is entered once more with new date, time, author, instrument and new parameter values, physical units and parameter comments and in that way the history is appended within the subsections. The attributed form in the same way consists of a list of parameters, the attribute 'data type', physical units and optional parameter values and comments (see table 3.3). There are no other attributes, because all input is manual, there is no inheritance, and only the syntactic of value input and necessity of parameters is checked.
All changes and manipulations concerning preparation, modification and storage conditions of the sample as well as a list of pointers indicating measurement series descriptions are chronologically stored. A viewing-tool allows to scan the entries and retrieve a history of the sample up to a certain date. It is possible to list all entries made by one author, either one chapter or the whole sample history or any combination e.g. all in situ preparations for one analytical tool made by one author since a specific point of time (e.g. change of manipulator). After every measurement series performed, a pointer to the measurement series will automatically be entered into the sample history (see data type attribute with the state 'pointer' in table 3.3). As can be seen in table 3.7 the sample history consists of a number of main sections. Table 3.8 shows an example of subsection 3.1.3. of the sample history.
1. Sample_properties2. Storage_environment
3. Sample_preparation
4. Measurement_series
Table 3.7: The main sections of a sample history
3.1.3. Second_chemical_cleaning
Date: 1995-02-06
Time:
19:10:23
Author: Brandl
Analytical_instrument: Auger
Ethanol boolean [] null /*parameter_comment*/
Aceton boolean [] yes
/*Reinstaceton......unter Ultraschall*/
Ultrasound boolean [] yes
/*parameter_comment*/
Other_solvent string [] null /*parameter_comment*/
Comment string [] null /**/
Table 3.8: Example of subsection 3.1.3 of the sample history
On one side it is necessary to split data gathered in the course of the measurements into different groups (see chapter 3.2.), on the other side it is less desirable to enter a parameter value several times. Therefore the idea of a defaulting system based on the inheritance of parameter values was born and became one of the basic features of MAXMIND. Additionally, most of the restriction limits for parameter values in the measurement (series) description are listed as parameters in the instrument description (e.g. Maximum_ primary_energy) and can be inherited too, in order to automate check of ranges.
To facilitate the handling of series of similar measurements (e.g. sputter depth profile) the concept of a measurement series is introduced. A series description hold all parameters, which are constant throughout the series. Individual measurement description contain only varying parameters. In order to further facilitate handling of manual input default values can be inherited from files at a higher level of hierarchy or from the previous file at the same level. As can be seen in figure 3.4, the single measurement description k+1 (1 <= k >= n) of a series of n single measurements can either inherit default values from the last measurement k (same level of hierarchy) or from the instrument description, the sample history or the measurement series description (files at a higher level of hierarchy). Additionally the restriction limits for checking the ranges can be inherited (e.g. from the instrument description) by special attributes like 'instminmax' (see table 3.2). After a measurement series (or a single measurement) has been performed, a pointer to the HDF-file produced is entered into the sample history and optional into the instrument description.
Fig. 3.4 Inheritance of parameter values for the measurement series description from the instrument description of one special instrument (e.g. dated state) and from the sample history of the sample at the time the measurement series processed. For the single measurement k+1 (1 <= k >= n) additionally inheritance from the measurement series description (n single measurements) is possible. Additionally, parameter values can be inherited from the last measurement k or the last measurement series. After every measurement series an update of the sample history is performed. An update of the instrument history is also possible.
For the measurement series description the inheritance possibilities of
the defaulting scheme are looking as follows: The measurement series
description can inherit either the default values from the instrument
description or the sample history, or the restriction limits for checking the
ranges from the instrument description. As can be seen in figure 3.6, the data
collection takes place in the following steps:
First, the data-get
function extracts all data values, which are defined in the measurement
series description form and which can be taken from the measured data.
In this way it is
Fig. 3.6: The flow diagram of the data collection for the measurement series description
possible to incorporate the data handled by the specific software of a special machine automatically. Default values for various parameters can automatically be inherited from the instrument description and the sample history or from the previous measurement series description. In the second step an editor session is invoked and values, which were left blank in the first step can manually be filled in (chapter 4.2.1). If needed, comments to single parameters or comments to chapters can be added for clarification. The input of a verbal description on how the measurement was performed and a description of the analysed region etc. is possible. In the present implementation a data-check function (chapter 4.1.1.) within the editor session is needed to evaluate the syntax of the user input and in case of an error to display a message and reinvoke the editor. In a later version a customised graphical user interface (see chapter 4.2.2) will replace the editor session and the data-check function in order to offer a more user friendly communication.
Attributed forms for the measurement series description and the measurement description controlling the conversion from raw data to description Vsets, are implemented as lists of parameters. These parameters are data objects specified by the parameter name, various attributes, physical unit and optional parameter value and comment. The lists of parameters are structured into main chapters and subchapters and can be extended in a simple way, if there is demand for a new parameter.
Fig. 3.7: The transfer from the measurement parameter raw data ("data source") to the measurement series description Vset and the measurement description Vset ("data destination") is made by a conversion program, which parses the attributed forms (see chapter 4.1.1.)
The measurement series description form and the measurement description form control the data conversion from the measurement parameter raw data, which can be seen as the "data source", to the measurement series description Vset and the measurement description Vset. In order to correspond with the instrument history form the (series) description forms of various analytical tools are structured into the same main sections but have varying subsections. Every section is a short list of attributed parameters. A formal grammar based on the attributes inheritance, editor mode, necessity, working environment, control and data type enables automatically parsing of the forms by lex and yacc programs (for further details see chapter 3.1.). In table 3.9 an overview of all possible attributes are depicted. Every attribute have to be placed once in the parameter after the parameter name in one of the few possible states.
List of attributes
parameter_name [attribute] [attribute] [attribute]... [pysical unit] [value] /*optional comment*/
Attribute "inheritance": manual, raw (aes, sam, stm..), default (), inst(), sh()
Attribute "editor mode": visedit (visible and editable), visual (only visible not editable), notvis (not visible)
Attribute "necessity": necess (necessary), unnec (unnecessary)
Attribute "working environment": khoros, nokhoros
Attribute "control": nocont (no control), minmax(a;b), instminmax(), select(a,b,c)
Attribute "data type": integer, real, string, boolean
Tab. 3.10: Possible attributes for inheritance, editor mode , necessity, working environment, control and data type of a parameter. The attribute raw() converts binary data, inst() and sh() extract data from the instrument description and the sample history. Instminmax() extracts parameters from the instrument description for controlling the range of parameters.
As can be seen in figure 3.8, the data conversion process comprises the following steps: First, the data-get function extracts all data values, which are defined in the measurement series description form and which can be taken from the measured data. In this way it is
Fig. 3.8: The flow diagram of the data collection for the measurement description Vset
possible to incorporate the data handled by the specific software of a special machine automatically. Default values for specific parameters can automatically be inherited from the instrument description and the sample history. In the second step an editor session is invoked and values, which were left blank in the first step can be manually filled in [Brandl 1996a]. Third the same procedure including the editor session takes place for every single measurement, but also values from the measurement series description are defaulted (higher level of hierarchy). If needed, comments to single parameters or comments to chapters can be added for clarification. The input of a verbal description into all main sections and subsections is possible concerning e.g. the vacuum equipment or special instrument preparations like bakeout etc..
In the following subchapters 3.3.4.1/2. (table 3.10 and 11) typical examples for sections in measurement (series) description Vsets are depicted.
3.3.4.1. One example of a section of a measurement series description
8.2. Heating
Start_temperature manual unnec instminmax(;,,Maximum_temperature) real [K]
null
Final_temperature manual unnec instminmax(;,,Maximum_temperature) real
[K] null
Temperature_points manual unnec nocont integer [] null
Linear_increase manual unnec nocont boolean [] null
Logarithmic_increase manual unnec nocont boolean [] null
Fixed_temperature manual unnec instminmax(0;,,Maximum_temperature) real [K]
null
Ms_duration inst(,,Standard_duration) unnec
instminmax(;,,Maximum_duration) real [s] null
Comment manual unnec nocont
string [] null
Table 3.10 'Heating' subsection of the measurement series description Vset of Auger Electron Spectroscopy. For further examples see the appendix.
3.3.4.2. One example of a section of a measurement description
5.1. Measurement_energies
Peak_energy_1 raw(sam) unnec minmax(0;2500) real [eV] null \*p.n.*\
Background_energy_1 raw(sam) unnec minmax(0;2500) real [eV] null \*p.n.*\
Peak_energy_2 raw(sam) unnec minmax(0;2500) real [eV] null \*p.n.*\
Background_energy_2 raw(sam) unnec minmax(0;2500) real [eV] null \*p.n.*\
Peak_energy_3 raw(sam) unnec minmax(0;2500) real [eV] null \*p.n.*\
Background_energy_3 raw(sam) unnec minmax(0;2500) real [eV] null \*p.n.*\
Peak_energy_4 raw(sam) unnec minmax(0;2500) real [eV] null \*p.n.*\
Background_energy_4 raw(sam) unnec minmax(0;2500) real [eV] null \*p.n.*\
Table 3.11 'Measurement_energies' subsection of the measurement description Vset of Scanning Auger Microscopy. For further examples see the appendix.
The sample history as it is stored on a portable storage medium (e.g. a floppy disk) is copied into the MAXMIND HDF-file. The original sample history is an editable ASCII-file, which lists relevant events concerning the sample, such as storage conditions, ex situ and in situ treatments and measurements. The sample history Vset stored within the MM HDF-file is first, in the same way as the instrument description Vset, necessary for a complete documentation and second in specific cases as default Vset for the measurement series description Vset. If the sample is analysed by several surface analytical instruments in different laboratories the sample history should be locally kept together with the sample itself to enable an immediate update after every measurement series.
The attributed forms for producing the instrument description Vsets for a variety of instruments and the sample history Vset consist of main sections and subsections. Every section is a short list of parameters, 'data type' attributes, physical units and optional parameter values and comments (see table 3.13). For further information about the attribute 'data type', and why there are no other attributes necessary for describing the information flow see chapter 3.1..
Instrument history / Sample History
Section_number Section_title
. Sub_section_number Sub_section_title
.
. Date:
. . Time:
. Author:
Analytical_Instrument:
Parameter attribute 'data type'
[unit] value \*parameter comment*\
.
.
.
Table 3.13: System of sections and subsections of instrument history and the sample history
The instrument history starts with the initial state of the instrument or with the state of the instrument, when the first description was made. If there is a change of one component of the instrument e.g. the analyzer, the appropriate subsection is entered once more with new date, time, author, instrument and new values, units and parameter comments (for an example see table 3.14).
8.2. Heating
Date: 1995-05-29
Time: 14:20:46
Author:
Reichl
Analytical_instrument: Auger
Maximum_temperature real [K]
1273 /*new heater*/
Maximum_power real [W] 80 /**/
Standard_duration
real [s] null /**/
Comment string [] null /*PI-contoller*/
Date:
1992-03-21
Time: 10:40:43
Author: Reichl
Analytical_instrument:
Auger
Maximum_temperature real [K] 1073 /**/
Maximum_power real
[W] 60 /**/
Standard_duration real [s] null /**/
Comment string []
null /*PI-contoller*/
Table 3.14: One example for a subsection of an instrument history. For further examples see the appendix
The instrument history can be accessed by a viewing tool. Thus the actual state as well as any dated state of the instrument including all hardware components as heater, vacuum equipment, ion gun, etc. can be displayed. Either the chronology of one chapter of the description or the whole instrument history can be viewed, as well as all history entries inserted by a certain author since a specific point of time.
The sample history starts with the manufacturing of the sample and leads from the sample storage conditions to sample preparations and measurement series description entries. If ex situ treatments or in situ treatments "happen" to the sample the special subsection describing the process is appended once more with new date, time, author, instrument and new values, physical units and parameter comments to the history (for an example see table 3.15).
3.1.2. Surface_treatment
Date: 1995-02-06
Time:
19:50:23
Author: Weis
Analytical_instrument: Auger
Polishing_with_diamant_paste boolean [] yes /**/
Paste_grain_diameter
real [um] 6 /**/
Other_method string [] null /**/
Comment
string [] null /**/
Date: 1995-02-06
Time: 17:10:23
Author: Weis
Analytical_instrument: Auger
Polishing_with_diamant_paste boolean [] yes /**/
Paste_grain_diameter
real [um] 9 /**/
Other_method string [] null /**/
Comment
string [] null /**/
Table 3.15: One example for a subsection of a sample history. For an example of an whole history see the appendix
All changes and manipulations concerning preparation, modification and storage conditions of the sample are chronologically stored. A viewing-tool allows to scan the entries and retrieve the whole sample history, one main section or even one subsection. Also possible is the display of all entries made by one author or any combination e.g. all in situ preparations for one analytical tool made by one author since a specific point of time (e.g. change of manipulator). After every measurement series performed, a data pointer indicating the measurement series' images and spectra raw data as well as the descriptive information will automatically be entered to the sample history. As the sample history is only appended and never changed, inconsistencies should not arise.
Individual measurement series description forms and measurement description forms are made for each analytical method, such as AES, SAM, XPS, SIMS, STM and AFM. These forms are structured into thematically different sections (e.g. instrument section, ion-gun section, heater section, analyzer section) and subsections (e.g. instrument geometry subsection). All data concerning one measurement series or one single measurement are gathered by the data conversion module and finally stored in a MM HDF-file by invoking the MM HDF input function.
The data conversion process in detail comprises, as can be seen in figure 4.2, the following steps: First, the data-get function extracts all data values, which are defined in the measurement series description form and which can be taken from the measured data. In this way it is possible to incorporate the data handled by the specific software of an arbitrary instrument automatically. Default values for specific parameters can automatically be inherited from the instrument description and the sample history. After every measurement series an entry of pointers referring to measured data is appended to the sample history automatically.
Fig. 4.1: General data flow shows data transfer and different storage media for spectrum or map raw data, measurement description, instrument history and sample history [Brandl 1995].
Fig. 4.2: The flow diagram of the data conversion for measurement series description and measurement description [Brandl 1996a]
In the second step an editor session is invoked and values, which were left blank in the first step can be manually filled in. In the present implementation a data-check function (see chapter 4.2.1.) within the editor session is needed to evaluate the syntax of the user input and in case of an error to reinvoke the editor. In a later version the editor session and the data-check function are replaced by a customised Graphical User Interface (GUI), which checks for syntactical and semantic errors during the input.
Third the same procedure including the editor session takes place for every single measurement, but also values from the measurement series description are defaulted. If needed, comments to single parameters or comments to chapters can be added for clarification. The input of a verbal description on how the measurement was performed and a description of the analysed region etc. is possible.
Figure 4.3 shows the data-get function in detail. The operation from the "sources" (measurement parameters, instrument description, sample history) to the measurement (series) description Vset is controlled by the measurement (series) description form. A conversion program parsing the attributed measurement (series) description forms extracts all parameter values, which can be taken from the measured data. In this way it is possible to incorporate header information of binary files and to convert measurement parameters from instrument specific raw data formats automatically. Default values for specific parameters can automatically be inherited from the dated state of the instrument history, (instrument description) the updated sample history or from the previous measurement (series).
The heart of the data-get function is a parser, which is based on the software tools lex (lexical analyzer) [AT&T 1988a, Herold 1992] and yacc (yet another compiler compiler) [Herold 1992, AT&T 1988b] and is described in the chapter implementation (5.2. Parser).
In the fourth step the MM HDF (Hierarchical Data Format [HDF 1993a]) -input function (see chapter 4.3.2.) combines the spectra and image raw data in a binary form and all parameters associated with the measurements in ASCII form in one physical file (MM HDF-file). It should be noted that the MM HDF-file contains the sample history up to the time of measurement and the instrument description. Thus HDF data files are self contained and during the evaluation process no reference to other files, which might not be locally available, is required.
Fig. 4.3: Data flow diagram of the data get function for the measurement series description Vset and the measurement description Vset [Brandl 1996b]
The raw data converter is based on MAXMINDs data dictionaries existing on two levels. The upper level are the description Vsets describing protocol data of various analytical tools. The lower level are instrument specific converter files, that hold the information of the converter keys of each parameter of one special instrument in a transparent form. The software in the background is based on lex and yacc functions, that parses the converter files line by line to do the conversion of the value and to check physical units and data types. On the other side the functions open the binary data files and take out the value for each parameter of the converter file respectively. As depicted in table 4.1 all lines consist of section number, section name, parameter name, offset, length, conversion type and conversion function (described by a few parameters). Examples for data converter files of a few instruments can be seen in the appendix.
Section_number Section number of parameters in the description
form
Section_name Section name of parameters in the description
form
Parameter_name Name of parameters in the description
form
Location Offset of parameter values within the raw data
files in byte
Length Length of parameter values within the raw
data files in byte
Data_type integer, real, string or
boolean
Conversion_types:
ii2d integer IEEE-format
to DEC-format
id2i integer DEC-format to IEEE-format
fi2d float IEEE-format to DEC-format
fd2i float
DEC-format to IEEE-format
null no
conversion
Value_correction_functions
lower_polynom_limit
lowest exponent of the correction polynom
upper_polynom_limit
biggest exponent of the correction polynom
Polynom_parameter1
1. coefficient of the correction polynom
Polynom_parameter2
2. coefficient of the correction polynom
.
.
.
Polynom_parameterN N. coefficient of the correction polynom
Table 4.1: Elements of a converter dictionary: section number, section name, parameter name, location, length, conversion types and correction functions (described by a few parameters)
The Value correction functions work as follows:
B = P1 . AL + P2 . AL+1 + P3 . AL+2 + ... + PN-2 . AU-2 + PN-1 . AU-1 + PN . AU
with:
A raw data value
B output value of the correction function
L
lowest exponent of the correction polynom
U biggest exponent of the
correction polynom
P1 ... PN polynom parameter 1 to N
File name
Length of the file header
Number of bands within the raw file
Band number
Data type
Dimension in x-direction
Dimension in y-direction
Table 4.2: A list of the parameters describing the instrument specific file header of binary raw data files
The data-check function scans trough the description looking for syntactic and semantic errors as well as checks the ranges of the input and sends an error message, if a "necessary" attributed parameter value is not filled in. In the case of an error a message is send and the editor is reinvoked (see loop in figure 4.4).
In a later version the editor session including the data-check function is replaced by a Graphical User Interface, which checks for syntactic and semantic errors, such as the range of a value, during the input.
Fig. 4.4: MAXMINDs input checking via an editor session [Brandl 1995]
The first internal functionality for creation of the GUIs main panel is the parsing of the attributed measurement (series) description. All following activities are based on the grammar of the description and are directly initialised at the start of the main panel creation.
The section list panel containing a list of main sections is created to enable navigation through measurement description (see figure 4.5). Each section is represented with one toggle button which is indented depending on the logical structure of the measurement description. Sections containing values are marked with visible border and the appropriated section panel is popped-up if the user push the 'section' button (it is possible to have more section panels at the same time on the screen). Section panels can be removed if one push the 'OK' button or the 'Cancel' button in the section panel, or push once more the 'section' toggle button on the section list panel.
Section panels are created by using the MM* objects and the Athena widgets (for further details concerning the implementation see chapter 5.4.). The panels contain items representing lines in the measurement description. One item in the section panel is made from the 'parameter name' menu button, the 'unit' label and the MM* value object. The menu containing the comment string is appended at 'parameter name' menu button. The 'parameter name' buttons containing a not empty comment string are marked with "visible border around" buttons, so the user can easy make difference between items containing either a comment or not. At the start of the section panel creation, for all parameters, that have the 'editor' attribute "visible", the appropriate parameters in the measurement (series) description are evaluated to set 'sensitive resource' of subwidgets treating the parameter value. The panels contain an 'OK' and a 'Cancel' button to accept or ignore changes done.
Fig. 4.5 Display of the GUI of a measurement (series) description
The HDF-input-function archives spectra and maps raw data and all sorts of descriptions in the MM HDF-files in a specific way. It archives the results of measurement and description information in different HDF-Vsets (Hierarchical Data Format Versatile sets, see chapter 4.3.2.) within one HDF-file. In that way it is possible to store whole measurement series (e.g. a time series of spectra), which might be very big amounts of data within one physical file, and to extract single measurements in a simple and straightforward way.
As can be seen by an example depicted in table 4.3, the MM HDF-file is divided into groups of Vsets. For each measurement series one headergroup exists including one comment file and groups of Vsets. The first of these groups (measurement_series_files) includes the measurement series description Vset, the instrument description Vset and the sample history Vset. Each of the three following groups (measurement_files) consist of the raw data of a spectrum, the raw description of a spectrum and the measurement description Vset.
HDF-FILE
HDF_file: MSFeS05.28
Group: Headergroup1
Data: comment (939 bytes) /*for special comments*/
Group: measurement_series_files
Data: msd_FeS.028 (8455 bytes)
/*measurement series description*/
Data: auger_25.02.95 (15655
bytes) /*instrument description of a special date*/
Data: FeS05 (45527
bytes) /*sample history*/
Group: measurement_files
Group: measurement_1 /*contains copies of the
following files*/
Data: m099802.dat (3584 bytes) /*copy of raw data of a
spectrum*/
Data: shf0998.dat (387bytes) /*copy of raw description of a
spectrum*/
Data: md_1 (4485 bytes) /*measurement description*/
Group: measurement_2 /*contains copies of the following files*/
Data:
s099822.dat (524288 bytes) /*copy of raw data of a map*/
Data:
sam0998.dat (4096 bytes) /*copy of raw description of a map*/
Data: md_2
(4639 bytes) /*measurement description*/
Group: measurement_3 /*contains copies of the following files*/
Data:
s099836.dat (1048576 bytes) /*copy of raw data of a map*/
Data:
sam0998.dat (4096 bytes) /*copy of raw description of a map*/
Data: md_3
(4469 bytes) /*measurement description*/
Table 4.3: The contents of the MM HDF-file of the measurement series MSFeS05.28. The file consists of one measurement series and is divided into groups of Vsets. The first group (measurement_series_files) includes the measurement series description Vset, the instrument description Vset and the sample history Vset. Each of the three following groups (measurement_files) consist of the raw data of a spectrum, the raw description of a spectrum and the measurement description Vset.
HDF-files are self-describing. For each data object in an HDF-file, there are predefined tags , that identify such information as the type of data elements, the amount of data, its dimensions, and its location within the file. The self-describing capability of HDF-files has important implications for processing scientific data. It makes it possible to fully understand the structure and contents of a file just from the information stored in the file itself. A program that has been written to interpret certain tag types can scan a file containing those tag types and process the corresponding data. Self-description also means that many types of data can be bundled in an HDF-file. For example, it is possible to accommodate symbolic, numerical and graphical data in one HDF-file [HDF 1993b].
The existence of a data index which identifies and describes the contents of the file, makes HDF a convenient file format for sharing data because everything the user needs to know about the data can be stored in the file together with the data. Hence, HDF eliminates the need for additional memos describing how and which data is stored in a file. HDF is a binary data format, which can be shared across different platforms without having to worry about machine dependent conversion problems inside the application programs. Due to its flexible structure, one can build sets of related data and then access them as groups or individual objects. One special type of these sets are the HDF-Vsets (Hierarchical Data Format Versatile sets [HDF 1993c]), which are hierarchically organised "subfiles" (similar to the tree-structure of a UNIX-style file system) within one physical file.
Two types of M-files can be used: scripts and functions. Both scripts and functions are ordinary ASCII files. While scripts automate long sequences of MATLAB commands, functions provide extensions to MATLAB. Scripts simply execute MATLAB commands found in the file and data storage is in the workspace. On the other hand functions may pass arguments, and variables, defined and manipulated in the file, are local and do not operate on the workspace.
MATLAB provides functions that enable users to add features of a GUI (graphical user interface) to MATLAB applications. As these functions are defined in M-files, these GUIs do not depend on the system MATLAB is used with. Also the GUI will look slightly different depending on the system, it will provide same functionality with (nearly always) the same code, on X-Windows under certain UNIX dialects, Macintosh or PC using Microsoft Windows.
The "MAXMIND Interface for MATLAB" (MIM) [Brandl i.w.] uses scripts as well as functions contained in special M-files to provide a wide range of functionality. MIM offers the following main functions:
* extracting the needed data from a HDF-file by calling the HDF-output library
* visualisation of image, spectrum and descriptive data in MATLAB
* loading data into the MATLAB workspace for further usage
* visualisation of 2D - plots showing the change of a certain parameter within one single measurement or whole measurement series
Table 4.4: Main functions of MAXMIND Interface for MATLAB
As can be seen in figure 4.6, a special GUI has been developed for the MAXMIND Interface for MATLAB to provide a user friendly communication and a transparent display of the menu. The GUI consists of an all-in-one window, displaying all of the required information and current status (e.g. HDF file in use, selected measurement series as well as single measurement or parameter) and offering all available functions of MIM. The GUI has been designed using the X-Window system, but is also fully portable to other systems like Macintosh or PC with MS-Windows.
The second component of the integrated processing system beside the MAXMIND Interface for MATLAB is a source-independent file format based on HDF, which allows to store all data relevant for analysis together with the actual raw data. For further details see chapter 4.3.. The link between HDF and MATLAB is managed by the MAXMINDs HDF output function allowing an automatic extraction of a selection of tags (Vsets) or data elements from an HDF file.
Fig. 4.6: MAXMIND Interface for MATLAB (MIM), an example for a MATLAB GUI with an all-in-one input panel for retrieving MM HDF-files and further evaluation tasks.
The problem of handling data acquired from different sources is managed by storing the raw data together with any additional information on instrument conditions, sample properties or measurement parameters in an open file standard (HDF). For further details see chapter 4.3.. The link between HDF and KHOROS is managed by a module allowing an automatic extraction of a selection of tags or data elements from an HDF file [Böhmig 1995a]. It dynamically builds parameter masks, which pop up on the screen and offers the user the possibility to assign Khoros-variables to data elements in the HDF file. A KHOROS toolbox supporting MAXMIND was developed. In that way a few specific functions can be invoked by popping up icons and pushing the start button. The functions are set up on KHOROS and HDF-library calls. The KHOROS specific icons for MAXMIND are depicted in table 4.5.
Beside the MAXMIND specific functionalities displaying the protocol information of a measurement series (see KHOROS 1.0.5. workspaces in the appendix), KHOROS offers the possibilities to display images or connect the conversion tools directly with image restoration [Böhmig 1995b] tools and then display the results. As can be seen in figure 4.7, a tool for the peak to background division of Auger maps is directly connected to an image plotting tool. The results, a peak to background image, an Auger spectrum and descriptive information about the heating process are displayed.
Fig. 4.7: KHOROS Interface for MAXMIND (KIM) an example for a KHOROS workspace for retrieving MM HDF-files and further evaluation tasks. For further example of KHOROS workspaces see the appendix.
* Extraction of the contents of an HDF-file
* ASCII file viewer of a sample history Vset
* ASCII file viewer of an instrument description Vset
* ASCII file viewer of a measurement series description Vset
* ASCII file viewers for all main sections of an measurement description Vset to pop up. It can be connected with a special measurement series description and then each single measure- ment description may be popped up
Table 4.5: Main functions of KHOROS Interface for MATLAB [Brandl i.w.]
The strategy to use an open image processing system like KHOROS has some disadvantages besides the asset of having access to a large set of available algorithms which can be flexibly connected to form more complex applications. One of the main disadvantages is that an application consisting of several modules does not allow to build an all-in-one graphical user interface panel, which combines all relevant or important parameters in one place (e.g. in one window).
It should be noted, that since a few month the new KHOROS version 2.0. was successfully installed at our institute. In comparison with KHOROS 1.0. the version 2.0. is very mighty, but there is still bug fixing going on.
All components discussed in this work, the data format HDF [HDF 1993a] as well as the data processing functions (data get and data check within the editor session, HDF-input, HDF-output), are based on public domain products. Both the data-get function and the data-check function parse structured ASCII-files. These parsers are implemented using the tools lex (lexical analyzer) and yacc (yet another compiler compiler) [AT&T 1988a, Herold 1992, AT&T 1988b]. For further details see chapter 5.2.. A raw data converter is needed for conversion of raw data to HDF binaries. Instead of the data check function within an editor session, data input via a Graphical User Interface (GUI) is also possible. The GUI of MAXMIND (detailed description of functionality in chapter 5.3.) is based on the X-Tool-kit Intrinsic (Xt) and on the Athena Widget Set (Xaw). It is structured into of a few layers and is built on top of the X Window System (available for most UNIX dialects and several other operating systems).
The data format (HDF) and the yacc and lex software tools are public domain base software, available for a large variety of platforms and operating systems (MS/DOS, various UNIX dialects, MacOS, openVMS...). All software is written in ANSI-C and is presently compiled on a DEC-5000/240 workstation under ULTRIX and on a DEC-ALPHA workstation under DIGITAL UNIX V3.2C. A preliminary set of low-level data processing routines based on the software package KHOROS [Rasure 1991] (also a public domain product) has been implemented to process the HDF-data [Böhmig 1995a]. As a second working environment MATLAB was introduced. Both, KHOROS and MATLAB, are well known data analysis environments in the surface analysis and image processing community. Although MATLAB is a commercial software product, there is nearly no limitation for the "public domain user", as the whole functionality is offered for both data analysis environments.
In future versions we intend to implement simple data-base-like retrieval operations on the HDF data elements, that can be invoked from both working environments, KHOROS and MATLAB or standalone.
A few complex MAXMIND specific objects (MM* objects) were built on top of the Athena Widgets: MMstring, MMreal, MMinteger and MMboolean. Each of the objects are built using several Athena widgets including widgets for specification of values (text widgets and/or command buttons) and/or control of values (increment and decrement button, and/or menu buttons including browsers displaying a list of values).
Fig. 5.1 Layer structure with MAXMIND specific objects (MM* objects) on top
The MM* objects include some complex functionalities to implement value control intrinsic to the measurement description Vset. For example MMreal is equipped with the following functionalities:
a) Minimum, maximum or both value bounding:
The user can not specify a
value bigger or smaller respectively than the specified minimum or maximum by
using the increment or decrement buttons (provided in MMreal and MMinteger). If
one tries to write values, that exceed the ranges, the widget is displayed in
the inverse colour and each character echo is followed by a 'beep' tone.
b) Restricting values to a selection of values:
If only some values (e.g. a
list of values) are permitted the increment and decrement buttons are not
displayed, and on there place there is menu button with a browser displaying
permitted values. In this case the text widget is not enabled for writing.
c) Character filter:
The user is not enabled to write characters not used
in specifying real numbers (e.g. letters and punctuation symbols except '.',
'e' and 'E').
Yet another compiler compiler (yacc): version 4.1. (DEC-ALPHA)
version
3.3. (DEC-5000/240)
Hierarchical Data Format (HDF): version 3.3.r4 (DEC-ALPHA)
version
3.3.r2 (DEC-5000/240)
Working environments:
MATLAB: version 4.2c (DEC-ALPHA)
KHOROS:
version 2.0.2. (DEC-ALPHA)
version 1.0.5. (DEC-5000/240)
Graphical User Interface (GUI):
X-Toolkit Intrinsic (Xt): version
X11R5 (DEC-ALPHA)
Athena Widget Set (Xaw): version X11R5
(DEC-ALPHA)
X Window System (X11): version X11R5 (DEC-ALPHA)
Supported platforms
DIGITAL-UNIX: version 3.2C. (DEC-ALPHA)
LINUX-PC: planed
HPUX: planed
OPEN VMS: planed
Every time when a program in C, Pascal or any other programming language is written, the source code has to be documented. And when the source code is appended or changed, the documentation is not updated and in consequence not very useful in many cases. The idea behind the Automatic Documentation Extractor (ADE) is very simple: Each time a new part of the source code has been written one have to write a little piece of text explaining this program fragment. When the program has been finished one may use the ADE to extract the text and some specific information from the source code. The created file then will contain the whole program documentation in LaTeX format. Using LaTeX the manuscript can be read on screen or can be printed out. The ADE can also handle software projects with a multitude of programs.
The ADE program has been developed for automatic documentation of the MAXMIND-package. Therefore ADE handles only LEX-, YACC- and C-code, but it can be easily extended for other code formats.
A program must consist of at least two files. The first file is always the header file, followed by an arbitrary number of files with program code. Each one of these files may be written in its own code format. So there can be files with LEX-, YACC- and C-Code. Files with PASCAL-code may also be used, but there are some restrictions to their usage. Different files are distinguished by their filename extension. These extensions are:
Header file .h
LEX file .lex
YACC file .yacc
C file .c
PASCAL file .p
Table 4.6: Filename extension used for automatic documentation of the MAXMIND-package
Within such a code file related subroutines can be grouped and provided with a group heading and a comment. The smallest parts of a code file are the subroutines which will be documented in tabular form.
* The name of the subroutine
* A short description what this program part does
* All interface information needed to use this routine
A key feature of MAXMIND is the strict separation of the software design and the development of data dictionaries (sets of parameters for various methods), thus data dictionaries can be modified without recompiling the software. On the other hand, in the future new software can be used with well established data dictionaries facilitating conversions of old data files. The data dictionaries include in the present version of MAXMIND are in the case of AES and XPS based on the work by M.P. Seah et.al. and C.J. Powell et.al.. Dictionaries for other methods have been set up by the author and are to be considered preliminary.
Beside the separation of data dictionaries, a few other main features of MAXMIND should be mentioned at that point. First, all description Vsets of MAXMIND, which are stored on three hierarchical levels, contain attributed data elements (parameters). Second, the data input into MM HDF-files can either be controlled by a graphical user interface (GUI) or command line. And third, the extraction of (series of) images and spectra data together with a selection of descriptive information from MM HDF-files is possible by automated repetitive evaluation tasks with the well known data analysis environments MATLAB and KHOROS.
Beside MATLAB and KHOROS a software interface to IDL will be developed. IDL, which is also a well known data analysis environment, will be the third working and evaluation environment for MAXMIND. In the nearer future the development and implementation of a VAMAS converter is planed, in order to make MAXMIND compatible to VAMAS.
This work as well as a first version of the MAXMIND software including all major components and its whole documentation will be available via WWW at the URL: 'http://www.iap.tuwien.ac.at/www/maxmind/'.
This work has been supported by Austrian Fonds zur Förderung der wissenschaftlichen Forschung, project no. S6201 and Digital Equipment Corporation, EERP project AU033.
Automatic Documentation Extractor (ADE)
Automatic extraction of text and
specific information from the source code.
Binary data
Binary data stored in HDF Vsets
Control
Attribute concerning permitted ranges of parameter values
Data check function
It scans trough the description files looking for
syntactic and semantic errors as well as checks the ranges of the input and
sends an error message, if a "necessary" attributed parameter value is not
filled in.
Data collection
Parameters and their values are collected from various
files (instrument description, sample history, measurement series description
and measurement description) creating the measurement (series) description
Vsets. The process is controlled by the measurement (series) description
form.
Data dictionaries
Catalogues of parameters for the description of the
interaction of different instruments and samples (various forms for instrument
histories, sample history, measurement series descriptions and measurement
descriptions)
Data get function
A conversion program parsing the attributed measurement
(series) description forms and extracts all parameter values, which can
be taken from the measured data.
Data type
Attribute defining if the data type of a parameter value
(integer, boolean..)
Description form
It consists of (attributed) parameters, that are grouped
into sections and subsections
Editor mode
Attribute describing if the value is visible and can be changed
within the editor session (e.g. full screen editor or GUI)
Editor session
It is processed with various editors (command line editors,
full screen editors, GUI) and is needed to complete measurement (series)
description.
Elements of raw data converter
An data object necessary for conversion of
one parameter value.
Graphical User Interface (GUI)
Interface to enable an user friendly
communication with MAXMIND. The used GUI is based on X-Toolkit Intrinsic
(Xt) and on the Athena Widget Set (Xaw), both belong to the X Window
System.
HDF
Hierarchical Data Format, a public domain product
from the National Center for Supercomputing Applications (NCSA)
HDF-Vsets
Hierarchical Data Format Versatile sets are hierarchically
organised "subfiles" (similar to the tree-structure of a UNIX-style file
system) within one physical file.
Header information
Information describing the storage of spectra and image
raw data
History form
It consists of parameters (only data type attribute), that are
grouped into sections and subsections
Inheritance
Attribute describing defaulting from a file of higher level of
hierarchy to the present file
Instrument history
An ASCII-file describing a certain instrument
(e.g. AES, SIMS, AFM,..). Each subsection consists of date and time (of
change), author, instrument and parameters
Instrument history form
Form for producing the instrument history consists
of sections and subsections (list of parameters). Parameters in the instrument
history form have only "type" attributes, because all input is manual, there is
no inheritance, and values and necessity of parameters are not checked except
for proper data type.
Instrument description
Dated state of an instrument history. Instrument
descriptions are stored as Vsets in MM HDF-files
Instrument description Vset
Instrument description being stored in a Vset
within a MM HDF-file
KHOROS
KHOROS is an image- and signal-processing package in the public
domain, developed by the University of New Mexico (Albuquerque).
KHOROS workspace
A window for connecting various KHOROS modules and process
them interactively.
Level of hierarchy
Defaulting is possible from a file of higher level to
one of lower level of file hierarchy
Lex
The lex (lexical analyzer) recognizes the lower-level constructs from
the input stream and picks them up as tokens, which are compared to grammar
rules.
M-file
Sequence of MATLAB commands stored in a disk file, that can be
executed. Two types of M-files can be used: scripts and
functions.
MATLAB
MATLAB, that means "matrix laboratory" is an interactive system
whose basic data element is a matrix
MAXMIND
Management And Exchange of Method
Independent Data (name of the software package described in the
present work)
(Single) measurement
In surface analysis mostly the recording of one
spectrum or one image
Measurement description
Description of a measurement, that can be stored in
a MM HDF-file (in a Vset)
Measurement description form
Form for producing the measurement description
consisting of sections and subsections (list of parameters).
Measurement description Vset
Measurement description being a subfile (Vset)
within the MM HDF-files
Measurement parameter raw data
Unconverted parameter values in raw data
files describing a measurement performed
Measurement series
Series of similar measurements (e.g. sputter depth
profile)
Measurement series description
Description of a measurement series, that
can be stored in a MM HDF-file (in a Vset)
Measurement series description form
Form for producing the measurement
series description consisting of sections and subsections (list of
parameters).
Measurement series description Vset
Measurement series description being a
subfile (Vset) within the MM HDF-files
MEX
MATLAB Extension functions are written in C or FORTRAN, compiled with a
special MATLAB compiler script and can only be executed from MATLAB.
MM
Short form for MAXMIND
MM HDF file
A binary file for storage of a whole measurement series within
several Vsets
MM HDF input function
It combines the output of the data conversion module
(names, values and units of parameters) and the measured raw data, concerning
one measurement, and stores them in a binary file called MM HDF-file
MM interface for KHOROS
A module allowing an automatic extraction of a
selection of tags or data elements from an HDF file.
MM interface for MATLAB
MAXMIND Interface for MATLAB uses scripts as well
as functions contained in special M-files to provide a wide range of
functionality
MM objects
MAXMIND specific objects (MM* objects) are built on top of the
Athena Widgets. These objects are: MMstring, MMreal, MMinteger and MMboolean.
They are used for the GUI
MMboolean
A special MM object equipped with data type relevant
functionalities
MMinteger
A special MM object equipped with data type relevant
functionalities
MMreal
A special MM object equipped with data type relevant
functionalities
MMstring
A special MM object equipped with data type relevant
functionalities
Necessity
Attribute describing if a parameter value is necessary for an
unambiguous description or not
Parameter
Data object used in MAXMIND consists of name, attributes, physical
unit, value and optionally a comment
Parameter name
Data element (string) e.g. primary_energy without spaces
Parameter comment
Optional appended comment describing the value
Parameter value
It is the value of the parameter and is of a certain data
type
Parser
The parser is based on the software tools lex (lexical
analyzer) and yacc (yet another compiler compiler). It interprets
attributed parameters
Physical unit
It is written within brackets: '[]'. Possible elements are
part of the SI unit system (e.g. m, K, s,...)
Protocol information
All information describing a measurement except
spectrum or map data (instrument, sample and measurement parameters)
Raw data
binary data stored in unconverted raw files
Raw data converter
Converters all raw data of the protocol information to
ASCII data in appropriate HDF Vsets and additionally the header information for
converting spectrum and map raw data to HDF binaries
Sample history
An ASCII-file describing a certain sample. Each
subsection consists of date and time (of treatment), author, instrument and
parameters
Sample history form
Form for producing the sample history consists of
sections and subsections (list of parameters). Parameters in the sample history
form have only "type" attributes, because all input is manual, there is no
inheritance, and values and necessity of parameters are not checked except for
proper data type.
Sample history Vset
Copy of a sample history at the special date, the
measurement was performed. Sample history Vsets are stored in MM HDF-files
Section
Main part of a description of a instrument, sample, measurement
series or measurement (e.g. Analyzer)
Spectrum or map raw data
Unconverted data of spectra or maps in raw data
files
Subsection
Description of one aspect of a description of a instrument,
sample, measurement series or measurement in detail (e.g. Analyzer
resolution)
URL
Uniform Resource Locator is a pointer to an object accessible via
internet
Vset
A "subfile" within a HDF-file (short form of HDF-Vset).
Working environment
Attribute indicating if the parameter value is visible
in the working environment
Yacc
The yacc (yet another compiler compiler) creates programs analyzing
the semantics of text input. The first processing step is performed by lex. The
analysis is controlled by a set of grammar rules compiled by yacc.
[AT&T 1988b] AT&T, UNIX System V / 386 Release 3.2 Programer's Guide Vol. 1, chapter 5, (1988)
[Binnig 1982] G. Binnig, H. Rohrer, Ch. Gerber and E. Weibel, Phys. Rev. Lett., 49, 57 (1982)
[Binnig 1986] G. Binnig, C.F. Quate and Ch. Gerber, Phys. Rev. Lett., 56, 930 (1986)
[Böhmig 1995a] S.D. Böhmig, K.W. Brandl, B.M. Reichl and H. Störi, Fresenius J Anal Chem, 353: 609-613 (1995)
[Böhmig 1995b] S.D. Böhmig, M. Schmid and H. Störi, Fresenius J Anal Chem, 353: 439-442 (1995)
[Brandl 1995] K.W. Brandl, S.D. Böhmig, G. Dreschler, B.M. Reichl and H. Störi, Fresenius J Anal Chem, 353: 443-446 (1995)
[Brandl 1996a] K.W. Brandl, G. Dreschler, T. Weis and H. Störi, Micro Chimica Acta, in press, (1996)
[Brandl 1996b] K.W. Brandl, G. Dreschler, T. Weis and H. Störi, ECASIA'95 proceedings, in press, (1996)
[Brandl i.w.] K.W. Brandl, G. Dreschler and H. Störi, Fresenius J Anal Chem, in work (1997)
[Briggs 1990] D. Briggs and M.P. Seah, Practical Surface Analysis (second edition), John Wiley & Suns Vol.1: 13 (1990)
[Bryson 1992] C. E. Bryson and G. E. McGuire, Surface Science Spectra, 1: 141 (1992)
[Campbell 1975] J. L. Campbell, B. H. Orr, A. W. Herman, L. A. McNelles, J. A. Thomson and W. B. Cook, Anal. Chem., 47, 1542 (1975)
[Coburn 1974] J. W. Coburn and E. Kay, CRC Crit. Rev. Solid State Sci., 4: 561 (1974)
[Dench 1988a] W.A. Dench, L.B. Hazell, M.P. Seah and the VAMAS Community, Surface and Interface Analysis, 13 : 63-122 (1988)
[Dench 1988b] W.A. Dench, L.B. Hazell, M.P. Seah and the VAMAS Community, Surface and Interface Analysis, 12 : 161-176 (1988)
[Digital Instr.] Digital Instruments, 520 E. Montecito St., Santa Barbara, CA 93193, USA.
[Dreschler 1996] Entwicklung eines Systems zur Dokumentation und Verwaltung oberflächenanalytischer Daten und seine Anwendung auf AES, SAM und STM, TU Wien, (1996)
[Feldman 1986] L.C. Feldman and J.W.Mayer, Fundamentals of Surface and Thin Film Analysis, Elsevier Science Publisher Co. Inc., New York, (1986)
[Friedbacher 1994] G. Friedbacher, T. Prohaska and M Grasserbauer, Mikrochimica Acta, 113, 179-202 (1994)
[Frommer 1992] J. Frommer, Angew. Chem., 104, 1325 (1992)
[Fuchs 1993] H. Fuchs, J. Mol. Struct., 292, 29 (1993)
[Goss 1993] C. A. Goss, J. C. Brumfield, E. A. Irene, R. W. Murray, Langmuir, 9, 2986 (1993)
[Grabke 1983] H.J. Grabke, Oberflächenanalytik in der Metallkunde, Deutsche Gesellschaft für Metallkunde e.V. : 29-51 (1983)
[Grasserbauer 1984] M. Grasserbauer, G. Stingeder, P. Wilhartitz, M. Schreiner, U. Traxlmayr, Mikrochimica Acta Ill, 317-348 (1984)
[HDF 1993a] HDF Manual, University of Illinois, Urbana Champaign, (1993)
[HDF 1993b] HDF Manual, University of Illinois, Urbana Champaign, NCSA HDF Basics: p. 3, (1993)
[HDF 1993c] HDF Manual, University of Illinois, Urbana Champaign, NCSA HDF Vset, (1993)
[Herold 1992] H. Herold, Lex und Yacc, Verlag Addison-Wesley, Bonn, (1992)
[Honig 1975] R. E. Honig, Thin Solid Films, 31, 89 (1975)
[Israelachvili 1991] J. Israelachvili, Intermolecular and Surface Forces, Academic Press, London, (1991)
[Leemput 1992] L.E.C. van de Leemput and H. van Kempen, Rep. Prog. Phys., 55, 1165-1240 (1992)
[Madey 1981] T. E. Madey, in Inelastic Particle-Surface Collisions, Springer Series in Chemical Physics Vol. 17, p. 80, Springer, Berlin (1981)
[Magonov 1993] S. N. Magonov, Appl. Spectrosc. Rev., 28, 1 (1993)
[Manne 1990] S. Manne, H. J. Butt, S. A. C. Gould, P. K. Hansma, Appl. Phys. Lett., 56, 1758 (1990)
[Manne 1991] S. Manne, P. K. Hansma, J. Massie, V. B. Elings, A. A. Gewirth, Science, 251, 183 (1991)
[MATLAB 1993] MATLAB Programer's Guide Vol. 1, the Math Works Inc., (1993)
[Pantano 1981] C. G. Pantano and T. E. Madey, Appl. Surf. Sci., 7, 115 (1981)
[Powell 1986] C.J. Powell and M.P. Seah, Surface and Interface Analysis, 9 : 79-83 (1986)
[Powell 1990] C.J. Powell, M.P. Seah and the VAMAS Community, J. Vac. Sci. Technol., A 8 (2) : 735-763 (1990)
[Puchhammer 1987] M. Puchhammer, Quantitative Methoden der Auger Elektronen Spektroskopie unter besonderer Berück-sichtigung von Titancarbonitriden, Dissertation, TU-Wien, (1987)
[Rasure 1991] J. Rasure and C. Williams, Journal of Visual Languages and Computing, 2:217, (1991)
[Rugar 1990] D. Rugar and P. Hansma, Phys. Today, 43, 23 (1990)
[Sarid 1991] D. Sarid, Scanning Force Microscopy, Oxford University Press,New York, (1991)
[Seah 1989] M.P. Seah, Surface and Interface Analysis, 14 : 407-412 (1989)
[Seah 1990] M.P. Seah, Surface and Interface Analysis, 16 : 135-139 (1990)
[Seah 1992] M.P. Seah, Surface and Interface Analysis, 19 : 247-252 (1992)
[Seah 1993] M.P. Seah, Surface and Interface Analysis, 20 : 243-266 (1993)
[Surman 1982] D. J. Surman, J. A. Van der Berg and J. C. Vickerman, SurJ: Interface Anal., 4, 16() ( 1982).
[Yoshihara 1992] K. Yoshihara, M. Yoshitake and the VAMAS-SCA Community, Surface and Interface Analysis, 18 : 724-728 (1992)
[Yoshihara 1994] K. Yoshihara and M. Yoshitake, J. Vac. Sci. Technol., A 12(4) : 2342-2347 (1994)
[Yu 1986] M.L. Yu, Nucl. Instr. and Meth. B15, 151-158, and references there in (1986)
Sample_history_Fe_bicrystal_2
1. Sample_properties
1.1.
Identification
Date: 1995-02-06
Time: 19:10:23
Author: Brandl
Analytical_instrument: Auger
Project_name string []
bicrystal_thomas /*parameter_comment*/
Manufacturer string [] Lejcek
/*parameter_comment*/
Sample_series_number string [] null
/*parameter_comment*/
Sample_number string [] null /*parameter_comment*/
1.2. Chemical_composition
Date: 1995-02-06
Time: 19:10:23
Author: Brandl
Analytical_instrument: Auger
Comment string []
Fe:97%___Si:3% /**/
1.3. Physical_form
Date: 1995-02-06
Time: 19:10:23
Author: Brandl
Analytical_instrument: Auger
Comment string [] null /**/
1.4. Surface_structure
Date:
1995-02-06
Time: 19:10:23
Author: Brandl
Analytical_instrument:
Auger
Comment string [] null /**/
1.5. Phase
Date:
1995-02-06
Time: 19:10:23
Author: Brandl
Analytical_instrument:
Auger
Solid boolean [] yes /*parameter_comment*/
Powder boolean []
no /*parameter_comment*/
Liquid boolean [] no /*parameter_comment*/
1.6. Crystallinity
Date: 1995-02-06
Time: 19:10:23
Author:
Brandl
Analytical_instrument: Auger
Single_crystal boolean [] no
/*parameter_comment*/
Bicrystal boolean [] yes /*parameter_comment*/
Poly_crystal boolean [] no /*parameter_comment*/
Amorph boolean [] no
/*parameter_comment*/
1.7. Electronic_properties
Date: 1995-02-06
Time: 19:10:23
Author: Brandl
Analytical_instrument: Auger
Supraconductor
boolean [] no /*parameter_comment*/
Conductor boolean [] yes
/*parameter_comment*/
Semiconductor boolean [] no /*parameter_comment*/
Insolator boolean [] no /*parameter_comment*/
Conductivity real
[1/(Ohmcm)] null /*parameter_comment*/
1.8. Definition_of_coordinates
Date: 1995-02-06
Time: 19:10:23
Author: Brandl
Analytical_instrument: Auger
Comment string [] null /**/
2. Storage_environment
2.1. Storage_contamination
Date:
1995-02-06
Time: 19:10:23
Author: Brandl
Analytical_instrument:
Auger
Comment string [] null /**/
2.2. Storage_temperature
Date: 1995-02-06
Time: 19:10:23
Author: Brandl
Analytical_instrument: Auger
Comment string [] null /**/
2.3. Storage_comment
Date: 1995-02-06
Time: 19:10:23
Author: Brandl
Analytical_instrument: Auger
Comment string []
Silikagel /*Unter Luftabschluss mit Trockenmittel*/
3.
Sample_preparation
3.1. Ex_situ_preparation
3.1.1.
Sample_manufacture
Date: 1995-02-06
Time: 19:10:23
Author:
Brandl
Analytical_instrument: Auger
Comment string [] wire_eroded
/**/
3.1.2. Surface_treatment
Date: 1995-02-06
Time:
19:50:23
Author: Weis
Analytical_instrument: Auger
Polishing_with_diamant_paste boolean [] yes /*parameter_comment*/
Paste_grain_diameter real [um] 6 /*parameter_comment*/
Other_method
string [] null /*parameter_notation*/
Comment string [] null /**/
Date: 1995-02-06
Time: 17:10:23
Author: Weis
Analytical_instrument: Auger
Polishing_with_diamant_paste boolean
[] yes /*parameter_notation*/
Paste_grain_diameter real [um] 9
/*parameter_notation*/
Other_method string [] null /*parameter_notation*/
Comment string [] null /**/
3.1.3. Chemical_end_cleaning
Date: 1995-02-06
Time: 19:10:23
Author: Brandl
Analytical_instrument: Auger
Ethanol boolean [] null
/*parameter_notation*/
Aceton boolean [] yes /*Reinstaceton......unter
Ultraschall*/
Ultrasound boolean [] yes /*parameter_notation*/
Other_solvent string [] null /*parameter_notation*/
Comment string []
null /**/
3.1.4. Deposition_of_a_conducting_thin_film
Date:
1995-02-06
Time: 19:10:23
Author: Brandl
Analytical_instrument:
Auger
Gold boolean [] null /*parameter_notation*/
Graphit boolean
[] null /*parameter_notation*/
Other_metals string [] null
/*parameter_notation*/
Comment string [] null /**/
3.2.
In_situ_preparation
3.2.1. Chemical_solvent_treatment
Date:
1995-02-06
Time: 19:10:23
Author: Brandl
Analytical_instrument:
Auger
Ethanol boolean [] no /*parameter_notation*/
Aceton boolean
[] null /*parameter_notation*/
Other_solvent string [] null
/*parameter_notation*/
Comment string [] null /**/
3.2.2.
Ion_gun_treatment
Date: 1995-02-06
Time: 19:10:23
Author:
Brandl
Analytical_instrument: Auger
Oxygen boolean [] no
/*parameter_notation*/
Neon boolean [] no /*parameter_notation*/
Argon
boolean [] no /*parameter_notation*/
Krypton boolean [] yes
/*parameter_notation*/
Cesium boolean [] no /*parameter_notation*/
Gallium boolean [] no /*parameter_notation*/
Other_ions string [] no
/*parameter_notation*/
Comment string [] null /**/
3.2.3. Heating
Date: 1995-02-06
Time: 19:10:23
Author: Brandl
Analytical_instrument: Auger
Maximum_temperature real [K] 570
/*dauernd im Bereich 100-200Cel*/
Duration real [s] 250000 /*ca. 3 days*/
Comment string [] null /**/
3.3. Sample_preparation_comment
Date: 1995-02-06
Time: 19:10:23
Author: Brandl
Analytical_instrument: Auger
Comment string [] null /**/
4. Measurement_series
4.1. Data_pointer
Date: 1995-02-06
Time: 19:10:23
Author: Brandl
Analytical_instrument: Auger
Raw_data rawpointer [] m099802.dat /**/
Raw_data rawpointer []
m099803.dat /**/
Raw_data rawpointer [] m099804.dat /**/
Raw_data
rawpointer [] m099805.dat /**/
Raw_data rawpointer [] m099806.dat /**/
Raw_data rawpointer [] m099807.dat /**/
Raw_data rawpointer []
m099808.dat /**/
Raw_data rawpointer [] m099809.dat /**/
Raw_data
rawpointer [] m099810.dat /**/
Raw_data rawpointer [] m099811.010 /**/
Raw_data rawpointer [] m099812.002 /**/
Raw_data rawpointer []
m099813.006 /**/
Raw_data rawpointer [] m099814.052 /**/
Raw_data
rawpointer [] m099815.066 /**/
Raw_data rawpointer [] s099899.dat /**/
Description_data descriptpointer [] shf0998.dat /**/
Comment string []
null /**/
4.2. Results
Date: 1995-02-06
Time: 19:10:23
Author: Brandl
Analytical_instrument: Auger
Comment string []
null /**/
1001. End_of_sample_history
1.2. Instrument_geometry
Date: 1995-06-17
Time: 10:29:46
Author: Reichl
Analytical_instrument: Auger
Emission_angle
real [deg] 48 /*48 +-3*/
Incident_angle real [deg] 45 /**/
Source_to_analyzer_angle real [deg] 0 /**/
Sample_normal_azimuthal_angle real [deg] 0 /**/
Sputter_source_incident_angle real [deg] 35 /**/
Sputter_source_polar_angle real [deg] 80 /**/
Sputter_source_azimuthal_angle real [deg] 60 /**/
1.3.
Calibration_of_measurement_spectrum
Date: 1995-05-29
Time:
14:20:46
Author: Brandl
Analytical_instrument: Auger
Reference_spectrum_description string [] null /**/
Pointer_to_reference_spectrum_raw_data rawpointer [] null /**/
Pointer_to_reference_spectrum_description descriptpointer [] null /**/
Other_method_(description) string [] null /**/
2. Vacuum_equipment
2.1. Vacuum_chamber
2.1.1. Specification
Date:
1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument:
Auger
Type string [] Perkin-Elmer_Physical_Electronics /**/
Manufacturer string [] Perkin-Elmer /**/
Series_number string [] null
/**/
2.2. Pre_vacuum_equipment
2.2.1. Specification
Date: 1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument: Auger
Type string [] null
/*Drehschiebervakuumpumpe*/
Manufacturer string [] Balzers /**/
Series_number string [] DUO_008A /**/
Pumping_speed real [l/s] 2.22
/**/
2.2.2. Vacuum_pressure
Date: 1995-05-29
Time:
14:20:46
Author: Brandl
Analytical_instrument: Auger
Maximum_pressure real [mbar] null /**/
Minimum_pressure real [mbar]
10E-3 /**/
Standard_pressure real [mbar] null /**/
Comment string []
null /**/
2.3. High_vacuum_equipment
2.3.1. Specification
Date: 1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument: Auger
Type string [] Turbo_molecular_pump
/**/
Manufacturer string [] Balzers /**/
Series_number string [] TPU040
/**/
Pumping_speed real [l/s] 40 /**/
2.3.2. Vacuum_pressure
Date: 1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument: Auger
Maximum_pressure real [mbar] null
/**/
Minimum_pressure real [mbar] 1E-10 /**/
Standard_pressure real
[mbar] null /**/
Comment string [] null /**/
2.4.
Ultra_high_vacuum_equipment
2.4.1. Specification
Date:
1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument:
Auger
Type string [] Ion_getter_pump_and_Titan_sublimation_pump /**/
Manufacturer string [] Ultek/Perkin-Elmer /**/
Series_number string []
null /**/
Pumping_speed real [l/s] null /**/
2.4.2.
Vacuum_pressure
Date: 1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument: Auger
Maximum_pressure real [mbar] null
/**/
Minimum_pressure real [mbar] 2E-11 /**/
Standard_pressure real
[mbar] null /**/
Comment string [] null /**/
2.5. Bakeout_heaters
Date: 1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument: Auger
Type string [] Heating_lamp /**/
Power real [W] 1400 /**/
Temperature real [K] null /**/
Comment
string [] null /**/
2.6. Residual_gas_analysis
Date:
1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument:
Auger
Mass_spectrometer string [] Balzers/QMG-101 /**/
UHV_ionization_vacuum_pressure_gauge string [] Varian/UHV-24 /**/
UHV_ionization_pressure_gauge string [] Varian/UHV-24 /**/
Other_types
string [] Spinning_rotor_gauge/SRG2 /*Gasreibungsmanometer*/
3. Source
3.1. Specification
Date: 1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument: Auger
Type string []
E_gun /**/
Manufacturer string [] null /**/
Series_number string []
null /**/
3.2. Primary_energy
Date: 1995-05-29
Time:
14:20:46
Author: Brandl
Analytical_instrument: Auger
Maximum_primary_energy real [eV] 10000 /**/
Minimum_primary_energy real
[eV] 500 /**/
Standard_value real [eV] 8000 /*2000, 4000, 8000*/
3.3. Intensity
Date: 1995-05-29
Time: 14:20:46
Author:
Brandl
Analytical_instrument: Auger
Maximum_intensity real [uA] 5
/**/
Minimum_intensity real [nA] 50 /**/
Standard_value real [nA] 150
/**/
3.4. Beam_geometry
Date: 1995-06-18
Time: 10:29:46
Author: Brandl
Analytical_instrument: Auger
Maximum_beam_diameter_in_x-direction real [um] 20 /**/
Minimum_beam_diameter_in_x-direction real [um] 2 /**/
Standard_value_x-direction real [um] 10 /**/
Maximum_beam_diameter_in_y-direction real [um] 20 /**/
Minimum_beam_diameter_in_y-direction real [um] 2 /**/
Standard_value_y-direction real [um] 10 /**/
Date: 1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument: Auger
Maximum_beam_diameter_in_x-direction real [um] 20 /**/
Minimum_beam_diameter_in_x-direction real [um] 2 /**/
Standard_value_x-direction real [um] null /**/
Maximum_beam_diameter_in_y-direction real [um] 20 /**/
Minimum_beam_diameter_in_y-direction real [um] 2 /**/
Standard_value_y-direction real [um] null /**/
3.5.
Beam_deflection
Date: 1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument: Auger
Maximum_step_length_in_x-direction
real [um] 32 /**/
Minimum_step_length_in_x-direction real [um] 2 /**/
Standard_step_length_in_x-direction real [um] 8
/*select(2,4,8,16,32)*/
Maximum_step_count_in_x-direction integer [] 256
/**/
Maximum_step_length_in_y-direction real [um] 32 /**/
Minimum_step_length_in_y-direction real [um] 2 /**/
Standard_step_length_in_y-direction real [um] 8
/*select(2,4,8,16,32)*/
Maximum_step_count_in_y-direction integer [] 256
/**/
Maximum_duration_per_point real [ms] null /**/
Minimum_duration_per_point real [ms] 1 /**/
Standard_duration_per_point
real [ms] 2 /*spectren: 50*/
Maximum_delay_per_point real [us] null /**/
Minimum_delay_per_point real [us] null /**/
Standard_delay_per_point
real [us] 5 /**/
Free_line_scan boolean [] yes /**/
Other_movement
string [] null /**/
4. Sample_holder
4.1. Specification
Date: 1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument: Auger
Type string [] null /**/
Manufacturer string [] null /**/
Series_number string [] null /**/
4.2. Sample_prevoltage
Date: 1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument: Auger
Maximum_sample_prevoltage real [V] null /**/
Minimum_sample_prevoltage
real [V] null /**/
Standard_value real [V] 0 /**/
4.3.
Sample_holder_geometry
Date: 1995-05-29
Time: 14:20:46
Author:
Brandl
Analytical_instrument: Auger
Specimen_normal_to_sample_site_normal_angle real [deg] null /**/
Sample_sites integer [] 12 /**/
Sample_holder_description string []
null /**/
4.4. Displacements
Date: 1995-05-29
Time:
14:20:46
Author: Brandl
Analytical_instrument: Auger
Minimum_shift_in_x-direction real [] null /*Specimen_normal*/
Maximum_shift_in_x-direction real [] null /*Specimen_normal*/
Minimum_shift_in_y-direction real [] null /**/
Maximum_shift_in_y-direction real [] null /**/
Minimum_shift_in_z-direction real [] null /**/
Maximum_shift_in_z-direction real [] null /**/
Shift_around_the_x-direction boolean [] null /*Specimen_normal 0-360*/
Shift_around_the_y-direction boolean [] null /*0-0*/
Shift_around_the_z-direction boolean [] null /*0-0*/
Other_displacement
string [] null /*step change of sites*/
5. Analyzer
5.1.
Specification
Date: 1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument: Auger
Manufacturer string []
Physical_Electronics /**/
Series_number string [] 25-260 /**/
5.2.
Analyzer_type
Date: 1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument: Auger
Cylindrical_Mirror_Analyzer_(CMA)
boolean [] null /**/
Spherical_Sector_Analyzer boolean [] null /**/
Double_Pass_CMA boolean [] yes /**/
Other_type string [] null /**/
5.3. Analyzer_mode_and_resolution
Date: 1995-05-29
Time:
14:20:46
Author: Brandl
Analytical_instrument: Auger
Maximum_energy_resolution_dE real [eV] null /**/
Minimum_energy_resolution_dE real [eV] null /**/
Standard_energy_resolution_dE real [eV] null /**/
Maximum_relativ_energy_resolution real [%] 1.6 /**/
Minimum_relativ_energy_resolution real [%] 0.4 /**/
Standard_relativ_energy_resolution real [%] null /**/
5.4.
Retarding_voltage
Date: 1995-05-29
Time: 14:20:46
Author:
Brandl
Analytical_instrument: Auger
Maximum_retarding_voltage real
[V] null /**/
Minimum_retarding_voltage real [V] null /**/
Standard_value real [V] null /**/
5.5. Electron_transmission
Date: 1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument: Auger
T=f(1/E) boolean [] null /**/
T=f(1/sqrt(E)) boolean [] null /**/
T=constant boolean [] null /**/
T=f(E) boolean [] yes /**/
Other_function string [] null /**/
5.6. Analyzer_geometry
Date: 1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument: Auger
Analyzer_shift
boolean [] no /**/
5.7. Analyzer_acceptance
Date: 1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument: Auger
Analyzer_axis_to_maximum_conical_acceptance_angle boolean [] null /**/
{
Maximum_conical_acceptance_angle real [deg] null /**/
}
Delta_maximum_to_minimum_conical_acceptance_angle boolean [] yes /**/
{
Maximum_conical_acceptance_angle real [deg] null /**/
Minimum_conical_acceptance_angle real [deg] 39 /**/
}
6.
Detector
6.1. Specification
Date: 1995-05-29
Time:
14:20:46
Author: Brandl
Analytical_instrument: Auger
Manufacturer string [] null /**/
Series_number string [] null /**/
6.2. Detector_type
Date: 1995-05-29
Time: 14:20:46
Author:
Brandl
Analytical_instrument: Auger
Channeltron boolean [] yes
/*12-stufig bis 3KV*/
Diode boolean [] null /**/
Scintillator_Photomultiplier boolean [] null /**/
Other_type string []
null /**/
6.3. Detector_parameters
Date: 1995-05-29
Time:
14:20:46
Author: Brandl
Analytical_instrument: Auger
Maximum_counting_rate real [MHz] null /**/
System_dead_time real [ns]
45 /**/
Maximum_detector_voltage real [V] 3000 /**/
Minimum_detector_voltage real [V] null /**/
Standard_value real [V]
null /**/
7. Ion_Gun
7.1. Specification
Date:
1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument:
Auger
Type string [] PHI_Auger_Model_04 /**/
Manufacturer string
[] Physical_Electronics /**/
Series_number string [] 04-191 /**/
7.2. Ion_Gun_Mode
Date: 1995-05-29
Time: 14:20:46
Author:
Brandl
Analytical_instrument: Auger
Differential_pumped boolean []
no /**/
Hot_cathode boolean [] yes /**/
Cold_cathode boolean [] null
/**/
Reactiv_sputter_source boolean [] null /**/
Plasma_source boolean
[] null /**/
Liquid_metal_source boolean [] null /**/
7.3.
Ion_gun_treatment
Date: 1995-05-29
Time: 14:20:46
Author:
Brandl
Analytical_instrument: Auger
Oxygen boolean [] null /**/
Neon boolean [] null /**/
Argon boolean [] null /**/
Krypton
boolean [] yes /**/
Cesium boolean [] null /**/
Gallium boolean [] null
/**/
Other_ions boolean [] null /**/
7.4. Primary_energy
Date: 1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument: Auger
Maximum_primary_energy real [eV] 5000
/**/
Minimum_primary_energy real [eV] 550 /**/
Standard_value real [eV]
2000 /**/
7.5. Intensity
Date: 1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument: Auger
Maximum_intensity
real [uA] 10 /*source 50mA*/
Minimum_intensity real [uA] 1 /*source 5mA*/
Standard_value real [uA] 5 /*source 25mA*/
Standard_value/A real
[nA/mm2] 80 /*Faraday-cup*/
7.6. Beam_geometry
Date:
1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument:
Auger
Maximum_beam_diameter_in_x-direction real [um] null /**/
Minimum_beam_diameter_in_x-direction real [um] null /**/
Standard_value_x-direction real [um] 500 /**/
Maximum_beam_diameter_in_y-direction real [um] null /**/
Minimum_beam_diameter_in_y-direction real [um] null /**/
Standard_value_y-direction real [um] 500 /**/
7.7. Beam_deflection
Date: 1995-05-29
Time: 14:20:46
Author: Brandl
Analytical_instrument: Auger
Maximum_step_length_in_x-direction
real [um] null /**/
Minimum_step_length_in_x-direction real [um] null /**/
Standard_step_length_in_x-direction real [um] null /**/
Maximum_step_count_in_x-direction real [] null /**/
Maximum_step_length_in_y-direction real [um] null /**/
Minimum_step_length_in_y-direction real [um] null /**/
Standard_step_length_in_y-direction real [um] null /**/
Maximum_step_count_in_y-direction real [] null /**/
Standard_sputter_duration real [s] null /**/
Standard_sputter_break_duration real [ms] null /**/
Free_line_scan
boolean [] null /**/
Other_deflection string [] lissajous_figure_like /**/
8. Heater
8.1. Specification
Date: 1995-05-29
Time: 14:20:46
Author: Reichl
Analytical_instrument: Auger
Type string [] null /*home made IAP TU-Wien*/
Manufacturer string []
Tectra_based /**/
Series_number string [] null /**/
8.2. Heating
Date: 1995-05-29
Time: 14:20:46
Author: Reichl
Analytical_instrument: Auger
Maximum_temperature real [K] 1273
/*new heater*/
Maximum_power real [W] 80 /**/
Standard_duration real
[s] null /**/
Comment string [] null /*PI-contoller*/
Date:
1992-03-21
Time: 10:40:43
Author: Reichl
Analytical_instrument:
Auger
Maximum_temperature real [K] 1073 /**/
Maximum_power real
[W] 60 /**/
Standard_duration real [s] null /**/
Comment string [] null
/*PI-contoller*/
1001. End_of_instrument_description