An analysis of type F2 software measurement standards for profile surface texture parameters

This paper reports on an in-depth analysis of ISO 5436 part 2 type F2 reference software for the calculation of profile surface texture parameters that has been performed on the input, implementation and output results of the reference software developed by the National Physical Laboratory (NPL), the National Institute of Standards and Technology (NIST) and Physikalisch-Technische Bundesanstalt (PTB). Surface texture parameters have been calculated for a selection of 17 test data files obtained from the type F1 reference data sets on offer from NPL and NIST. The surface texture parameter calculation results show some disagreements between the software methods of the National Metrology Institutes. These disagreements have been investigated further, and some potential explanations are given.


Introduction
The need to measure surfaces in manufacturing stems from an increasing need for precise and accurate component control, both in terms of the geometry of the component's surfaces and the surfaces' ultimate function [1,2]. As manufactured parts get more complex, the effect of their micro-scale attributes plays a more important role in their functional properties, with the surface of a component serving as the point of interaction between itself, other components and the environment [3]. The fine structure, or texture, of a surface can influence mat erial properties such as durability [4,5], and consequently there is an increasing need for greater surface control.

Surface texture parameters
Profile surface texture parameters facilitate greater surface control by giving the surface a quantitative value [3,6], allowing for easier comparisons with other surfaces. Profile surface texture parameters are obtained through a series of mathematical operations applied to measured data for the surface, including form removal, filtering and parameter calculation [7,8]. The profile surface texture parameters are defined in ISO 4287 [9]. Each parameter is given an identifier, description and mathematical definition. The mathematical operations required to determine a parameter from surface measurement data are performed computationally; using software packages with measurement instruments, or third-party alternatives. ISO 5436-2 introduced 'software measurement standards', created with the intention of being as accurate as possible, in order to verify the results of a measurement software package [10]. Software measurement standards come in two types: type F1 reference datasets with certified results, and type F2 reference software which calculate surface texture parameters for any input file.
With several NMIs producing reference software, it becomes necessary to compare them with each other to establish equivalence of the software measurement standards. The definitions laid out in the ISO 4287 and 5436-2 standards must be interpreted and adapted to software, and may be implemented in multiple ways, producing different results. Additionally, some ISO definitions may present ambiguity, leading to further variations in the end result. A good example of an ambiguity in the ISO definitions is shown in [18], where Leach and Harris reveal an ambiguity in the definition of profile element discrimination, which leads to the number of profile elements counted in a certain length to be unclear, producing different values for the RSm spacing parameter. The RSm ambiguity is just one, fairly severe example of ambiguity in the parameter definitions 4 . It is expected that there are more ambiguities elsewhere in the ISO steps required to go from a primary profile to a surface texture parameter value.

Previous software comparisons
Comparison allows differences in the obtained parameter values to be discovered, giving the potential to highlight ambiguities in the ISO specification standards in the hope that they may be better defined. Research carried out by Baker et al [20] and Koenders et al [21] performed comparisons between many laboratories across the world, obtaining roughness parameters for a variety of different physical measurement standards. These comparisons highlighted the RSm parameter variations mentioned by Leach and Harris. In 2009, Li et al [22] focussed more on the in-house software offerings of NPL, PTB and NIST, along with three commercial software packages. Li's report went into further detail about the software packages, identifying some differences in software implementation. For example, Li et al highlighted that NPL uses interpolation of the input data points to create a continuous profile, whereas PTB and NIST work with a discrete profile. Li et al performed their comparison with six type F1 reference data sets, again finding generally good agreement between the NMIs. The software measurement standard comparison used the PTB software 'RTPB v1.05', which has since been updated, bringing the values obtained by PTB much closer to those obtained by NPL and NIST, particularly for the average ordinate parameters (Ra, Rq, etc). Li et al's work also highlighted the increased disagreement for RSm values and the need for a better definition for this parameter, along with the Rc parameter. More recently, Paricio et al [23] performed a similar experiment, comparing the software on offer from NPL, PTB and NIST. Paricio's work had a greater focus on the user side of the software, commenting on the usability for the end-user. The comparison was performed using data files created in-house, from rectilinear sections. The results showed good agreement for a small selection of profile and roughness parameters, with PTB's results differing slightly from NPL and NIST, showing a tendency to provide smaller values.

In-depth comparison
While it is clear that comparisons of NMI parameter calculation software have been carried out before, there is potential to delve deeper into the results obtained, whereby a comparison is made with equal focus on parameter results and software implementation, enabling the opportunity for links to be made between the two. Such work has the potential to highlight how subtle differences in implementation of type F2 software measurement standards affect calculated parameter values. A comparison of this nature could identify areas of the ISO specification standards which require clearer definitions to avoid ambiguity.
The aim of the work presented in this paper is to perform an in-depth analysis of the type F2 software measurement standards available from NPL, PTB and NIST. This analysis will comprise both a comparison of the parameter values produced by each NMI software for a selection of test files, and an investigation into the differences in implementation of the standards, workflow routes and default settings chosen by each of the NMI software packages. The combination of the two aspects has the potential to allow any observed implementation differences to explain differences in the parameter results. While areal surface texture parameters have been produced [24], this paper focuses on profile surface texture parameters only due to their easier theory and wider use in industry.
The work presented in this paper is organised as follows. Section 2 details the implementation of the ISO specification standards for profile surface texture parameters for the software measurement standards, discussing the different software choices in detail and the algorithmic flow of each software package. Section 3 provides a description of the experiment methodology, justifying the test data files used and the process of performing the comparison. Section 4 discusses the results of the profile surface texture parameter calculations. Finally, section 5 summarises the outcomes of the work and concludes the paper.

Input file requirements
All three NMIs accept the .SMD file format, as defined in ISO 5436-2. NIST and PTB also accept .SDF files, which is the ISO-defined file-type for areal software measurement standards [25]. The .SDF format is a useful addition, as it allows profile and areal measurements to be pre-processed for parameter calculation in the same way, saving time for users of the software that use both measurement types. Additionally, the NIST software accepts the .TXT format, a common text file type, and PTB accepts the .PR filetype, a simplified version of the .SMD from an old Breitmeier UBM instrument. Although the NPL software is restricted to the SMD format, to facilitate a wider use of the software NPL provide a 'data file converter' at http://161.112.232.32/softgauges/Converter.aspx to include .SDF, .PRF and .TXT file formats.
All three NMIs assume the height value points within the input file are uniformly spaced along the X-axis. Uniform spacing is part of the .SMD definition in ISO 5436-2, and allows for a much simpler analysis of the file. On top of uniform spacing, NPL assumes some initial processing has already been carried out. In line with the definitions in ISO 5436-2, the NPL software requires an input of a primary profile. Using a primary profile means the input file must already have had the form removed, and must be λs filtered, so that any wavelengths shorter than those associated with roughness are removed. NIST and PTB, however, have no such restrictions and include options for form removal and λs filtering, allowing them to work with files with no prior processing undertaken.
In addition to uniform spacing, the height value points should also be referenced from a zero-value mean line. The parameters given in ISO 4287 are defined using equations that assume this mean line calculation, and thus there is no explicit definition of how to calculate the mean line. As different software packages may calculate a different mean line reference, different parameter values could be obtained.

Algorithm flow
To better understand software measurement standard implementation differences, it is necessary to determine the options each software package gives, including identifying all choices available to the user and highlighting the different paths that a user could take through the software.
A good way to visualise the routes taken through the software is to create flow diagrams. The flow diagrams for NPL, PTB and NIST are given in figures 1-3, respectively, located toward the end of the paper due to their size. Each flow diagram shows the different software options and algorithmic routes that can be followed, along with inputs made by the user. On the PTB and NIST flow diagrams, a thick line is used to highlight the path through the software package that offers the greatest similarity to the NPL software package, which is useful for more direct comparison between NMIs. This is discussed in more detail in section 3.1. The software options filled in grey highlight any default settings in the software. What is immediately clear is the significant difference in complexity between the three software packages.
The NPL software is the simplest of the three. Once the file is input, there are only two sections to the software: λc filter and parameter calculations-all that is required according to ISO 5436-2. The NPL software has no user options; once the file is chosen, the process is autonomous and the parameter values are calculated. This simplicity keeps the software package streamlined; its scope is accurately defined to match the requirements of a type F2 software measurement standard according to ISO 5436-2, and the software avoids the added complexity of additional features that can introduce further error or ambiguity. Whilst a single route ensures all parameter values are obtained through the same method and a good adherence to the ISO 5436-2 definitions, it is not very flexible, and should another filtration method be more suitable for a particular file, there is no way to take advantage of that. The filter used by the software is a linear Gaussian convolution, as defined in [7]. Following the filtration, the data is interpolated to form a continuous representation using a natural cubic spline [26]. The software uses this continuous representation to evaluate the parameters using the exact integral forms given in ISO 4287. For the waviness and roughness profiles, a length of λc is removed from each end of the profile to avoid any end effects that may be caused by the filter application. Following parameter calculation, the user can choose the output format of the parameter values; either a .SMD file or .HTML file.
The PTB software is more complex than that from NPL, partly because of the addition of form removal and λs filtering, adding two steps before the NPL software begins. The order  of these steps is also up to the user, as is whether they are used at all; both are optional. The most dominant feature of the PTB flow diagram is the amount of filtration choice given to the user. The PTB software gives the user three λs choices, two form removal choices, and ten combinations of λc filters; six to perform the main filtration, and four secondary options to obtain the material ratio parameters. These filters include Gaussian convolution [7], Gaussian regression [27], Gaussian with end effect management [28] and spline filters [29]. This amount of choice makes for a very flexible system, but potentially adds confusion for inexperienced users. Following the filtration, the choices become more limited. Users are able to select which parameter values are exported, along with certain inputs such as height/spacing discrimination values. The user can also choose the algorithm with which to calculate the material ratio parameters, which are not included in the NPL software. Following these parameter choices and their calculation, the results can be exported in .CSV file format and a .PDF report. During the filtration step of the software, the data is shown to the user visually, along with all obtained profiles. A visual representation of the data is a useful addition, as seeing the data allows for a much better understanding, compared to a long dataset of raw values.
The NIST software at first looks highly complex, however, closer inspection reveals that the choices available to the user are relatively simple; there are instead more optional steps following the parameter calculations. First, the user has the option of not only choosing their own data file to run through the software, but also a reference data file from NIST's database. The ability to load files straight from the NIST database makes it easier for users who are using a NIST type F1 data file with their own software, as they can run the same file through the NIST software without having to download the file first. The user interface for the NIST software uses click-able tabs along the top of the window for selecting different sections of the software, allowing user control over which operations are performed. Additional sections in the software include power spectral density calculation, autocorrelation/cross-correlation and bearing-area-curve determination. Each of these additional sections come with simple choices to the user, such as the profile on which to operate and which method to use. As with PTB, NIST includes optional form removal and λs filtering. For λc filtering, the choices are more limited than those given by PTB. The user can choose between Gaussian or 2RC filter methods; 2RC choices are between recursive and convolution methods, whereas Gaussian methods are between convolution, 'Fast Gaussian' and fast Fourier transform. For the Gaussian methods, the user can also choose whether to use a λ ± c 0.5 or λ ± c Gaussian window, which dictates how large the cut-off regions are for the roughness and waviness profiles. Similar to PTB, the NIST software also shows the input data visually, albeit at a lower resolution.

Software choices for greatest comparability
With so many different routes through the software, it is important to establish a particular route for the comparison, chosen such that the software packages can be compared effectively. Choosing similar options for each software package will minimise the number of potential sources of variation and make it easier to investigate any differences that do arise.
As the NPL software has only one algorithmic route available, it makes sense to choose options in the other two software packages to best match the steps taken by NPL. The software route includes the following: 1. The input data given is a primary profile; it must have form removed and be λs filtered prior to input into the software. 2. The λc filtration shall be performed by a Gaussian convolution, as described in ISO 16610-21.
3. The parameters shall be calculated with the definitions given in ISO 4287. 4. For parameters that require height/spacing discrimination, a height discrimination of 10% of Xz (the sum of the height of the largest peak and lowest valley within a sampling length, ISO 4287) and spacing discrimination of 1% of the sampling length will be used. These are the default values as defined in ISO 4287. 5. If possible, no additional steps shall occur.
For point four in the list above, the discrimination values of 10% of Xz and 1% of the sampling length are taken from sections 4.1.4 and 4.3.1 in ISO 4287. This definition presents some ambiguity, as it can be interpreted as ±5% around the mean line, ±10% around the mean line, or 10% of the peakto-valley height in a profile element. It is unknown how each of the NMIs have interpreted this definition, and so the Xz discrimination value may be a source of potential differences in the parameter results.
The closest routes through the NIST and PTB software are shown by the thick lines on the flow diagrams in figures 2 and 3. For both NIST and PTB, it was possible to avoid extra steps, such as form removal and λs filtering. The NIST software, being tabular in nature, allowed the selection of only the λc filtering and parameter calculation steps. The PTB software is more sequential than the NPL software, forcing users to go through all steps of the software including material ratio parameter calculations, which are not required in this comparison, as the NPL software does not calculate them. However, while material ratio parameter calculations added time to the processing of the data files, it did not affect the filtration or values of the other parameters.
Both software packages allowed the selection of a Gaussian convolution as the λc filter, matching that used by NPL. The NIST software also allowed the use of a λ ± c Gaussian window, leading to a cut-off length of λc from each end of the filtered profiles, matching that of NPL. Both NIST and PTB also allowed the selection of the same ISO 4287 parameters that NPL calculates. Combined, these options allow for pathways through the software packages that are sufficiently close to allow a meaningful comparison. As mentioned above, the software options filled in with grey lines show the default choices in the software. These do not always match the NPL software, for example by having a form removal method enabled by default, or a different filter method selected that doesn't match the suggested method from the ISO specification standards. These differences mean selections must be actively changed by the user to obtain results comparable to another NMI, making it harder for a layman to get comparable results.
3.1.1. Sampling length ambiguity. ISO 4288 defines the evaluation length for the roughness profile to be built from a total of five sampling lengths, where each sampling length is equal to the length of λc. However, ISO 4288 does not specify from where the sampling lengths will be taken if the profile length is longer than λc 5 . The NPL software chooses to take the five sampling lengths from the centre of the profile, but it is not known whether NIST and PTB choose to do the same. This lack of guidance in the specification standards is another source of ambiguity than can lead to different parameter results, as the NMI software packages may be calculating the parameter values from sampling lengths with different starting points.

Choice of test files
With the software routes understood, a selection of test data files can be chosen to run through the software to compare the values. To make the comparison as useful as possible, the   test files should be chosen to ensure a wide variety of profile types. The aim of the file selection is to test various aspects of parameter calculation, and identify the situations where differences may occur. The test files should include variations such as: • Profile frequency-The density of the peaks and valleys of the profiles. • Periodicity-The repeatability of the profile elements.
Profiles that display a repeatable pattern have high periodicity; profiles that show significant variation between profile elements have low periodicity. • Master piece profiles-Profiles that are taken from real surfaces and represent realistic surface finishes e.g. polished, ground.
• Simulated profiles-Profiles that are numerically generated and present as simple shapes, e.g. sinusoids, steps, squares. The test files used were type F1 reference data files taken from both NPL and NIST. Taking files from NIST and NPL type F1 databases ensures the test files used come from reliable sources, and allows the test to be repeatable by anyone. In order to comply with the input requirements of NPL, primary profiles must be used. The NPL datasets were assumed to already comply with their own software requirements, however, this proved to be a false assumption, as discussed in section 4.5.1. Although the NIST datasets are by default given as total profiles, primary profiles are included in the downloadable .ZIP folder. From the full list of data files, seventeen test files were selected, ten from NPL and seven from NIST, which exhibit a variety of profile characteristics from the list above. The chosen files are shown in figure 4.

Running files through the software
When attempting to input the files into the different software packages, some errors were found.
3.3.1. NIST input file issues. ISO 5436-2 defines the standard file-type for profile datasets to be .SMD [10]. ISO 5436-2 also gives a description of how the file should be structured, including the different records in the file and what they should contain. ISO 5436-2 also defines that each line, record and file should be ended with specific control characters, which are ASCII characters used to give information to the software reading the file, and are not represented by any written symbol. As a result, most common text editors do not show these characters, and a more advanced program is needed to read or write them.
It was found that in order for files to be accepted by the NIST software, the .SMD file had to be terminated with the 〈SUB 〉, 〈CR 〉 and 〈LF 〉 control characters. ISO 5436-2 states 'The last record is further terminated by an end of file (〈ASCII 26〉)' (〈26 〉 is the SUB control character). While somewhat ambiguous as to what else should go on the final line, the examples given in the document show the 〈SUB 〉 character should be on its own. Because of this, the NPL files, which terminated with just 〈SUB 〉 in line with the ISO examples, could not be opened by NIST.
It was found that the NIST software would only open the NPL files if the date in the revision number inside record 1 was changed from '2000' to '1999'. Changing this date has a knock-on effect of invalidating the checksum given at the bottom of the file, which is calculated using the ASCII values from the first three records. For the file to be accepted, the checksum needed to be updated.
A further error was found in some of the NIST type F1 files. The files used were primary profiles from the total profiles listed in the NIST database. It appears that in recreating the .SMD files with the primary profile data values, the number of points in the profile were not recounted. For some files, a small number of points had been removed from the profile, perhaps due to an effect of the form removal or λs filter. However, the first record in the .SMD file defines the number of points in the file, and this number had not been updated to the true number for the primary profile, and instead matched the number for the total profile. In order for these files to work, the number of points had to be recounted, and the first record in the .SMD updated.

NPL input requirements.
Because the NPL software has no user input once the file has been selected, all settings and required information must be included in the .SMD file. The .SMD must include which parameters to calculate, and the λc value for the Gaussian filter. While versions of the NPL datasets could be downloaded with this information already in the .SMD file, the NIST files did not. To make the NIST type F1 files ready for use with the NPL software, each file had to include these NPL software instructions. As including the software instructions edits the characters in the .SMD file; the checksum also had to be recalculated and updated for these files.

Software outputs.
Each file was processed through each software package using the user options shown in figures 1-3. All files were run with λ = c 0.8 mm. Keeping λc fixed for all files had several benefits; it reduced the complexity of the experiment, was the default setting for the NPL downloaded files, and allowed for potential effects to be seen for test files where λ = c 0.8 mm is outside the optimum value for the cut-off filter. Once all parameter calculations were complete, the next step was to extract the parameter values from the software in order to analyse them.
Each software package outputs the parameter values in a different format. The NPL software allows either a .SMD or .HTML file to be saved. The PTB software gave the parameter values in the form of .CSV, and gave a .PDF report. The NIST software only offered a .PDF report for download, which was not an ideal format for extracting information. Instead, the parameter values were extracted from an on-screen table and saved as a .TXT file. As all three software packages produced different files, the relevant information had to be extracted from each output file and reformatted, so that all the parameter values were given in the same format.

Results and analysis
Once the primary profile test files were suitably pre-processed to be used in each NMI reference software package, each file was run through the reference software packages and parameter values were obtained. The parameter values showed good agreement between NMIs for a many of the profile parameters and test files. Examples of this include average ordinate parameters such as Pa and Rq, and roughness parameters in general. This is unsurprising, as these parameters are the most simply defined and hence leave little room for interpretation. Test files that were simulated and periodic in nature, such and sin1 and saw123, also showed generally good agreement across many parameters. However, some areas of interesting disagreement were identified between the NMIs, and these are highlighted and discussed in the sections below.

PTB negative Xv parameter values
It was found that PTB displayed its Xv parameter values as negative. ISO 4287 defines the Xv parameters using the magnitude of the valley depth, thus making the negative result non-compliant with the definition 5 . For the following analysis, the magnitude of the Xv values was used and displayed.

NPL sharp step overestimation
During the analysis it was found that, compared to the results obtained by NIST and PTB, the NPL software showed an overestimation for some parameter values. The overestimation was found mainly on peak/valley parameters, where no averaging of the ordinate values occurs, for test files that had very sharp steps. Some representative examples are given in figure 5, which shows the relative parameter values for the square and steps files, with NIST as the arbitrarily chosen reference where Xn is the value of any surface texture parameter, Xn ref NMI is the value of the same parameter for the chosen reference NMI and Xn norm is the normalised value of the original parameter. As all normalised parameter values for the chosen reference are equal to one, their values are omitted from the graphs. Figure 5 shows that for both files, the Primary and Roughness peak/valley parameters obtained by NPL are around 20% larger than the values obtained by the other two. The overestimations for peak/valley parameters suggest that the interpreted profiles have a larger amplitude in the z-direction than those of NIST and PTB. Both NIST and PTB assess the discrete data points directly, however, NPL uses a cubic spline function to interpolate the data and produce a continuous representation. While interpolation can lead to more accurate parameter calculations for many profile shapes, for very steep steps, as found in both square and steps, the cubic spline can oscillate, causing overestimations of peak and valley values. A simple example of this oscillation is shown in figure 6, where a cubic spline function has been used to fit a simple top-hat function. At the step points, overestimation is shown as the spline oscillates to meet the required points. It is expected that a similar effect is happening with the NPL software.

PTB large waviness values
The PTB software was observed to obtain larger waviness parameter values than NPL and NIST, most prominently for some of the peak/valley parameters, occurring for almost all files. The larger waviness values were also present on some files for the average ordinate parameters (Wa, Wsk etc). Figure 7 gives examples of some of these, showing PTB in yellow giving larger waviness values than the other two. The top graph in figure 7 shows the Wp parameter in more detail, showing several files such as EDM16ms, Mill and cor10gau with much higher Wp values. The bottom graph looks at the EDM16ms file specifically, and reveals that PTB obtained larger values than NIST and NPL for several waviness parameters, including Wv, Wz, Wku and Wq. This effect is also shown in figure 5, where PTB gives substantially larger values for several waviness parameters for both the square and steps test files.
After discussions with PTB directly about the large waviness parameter values in comparison with NPL and NIST, it was discovered that PTB treat the ends of the waviness profile differently to NPL and NIST. In order to account for end effects, both NPL and NIST cut off the ends of the profile of length λc, and assess the remaining central portion. PTB, however, does not do this for the waviness profile. This causes the waviness profile to be longer and include more data points in the PTB software than the other two, leading to a greater chance of there being another peak (valley) with a high (low) value and resulting in a larger final parameter.
The reason for this difference in software implementation between the NMIs stems from an ambiguity in the ISO definition. The evaluation lengths for the primary and roughness profiles are defined in ISO 4288 section 4.4 [8], where it states the primary profile is equal to the length of the feature being measured, and the roughness profile is equal to λc 5 . The waviness profile, however, has no such definition. ISO 4288 is, therefore, unclear as to whether the waviness profile length should be made similar to the roughness profile, or the primary profile. It appears that NIST and NPL have chosen to treat the waviness profile the same as the roughness profile, and PTB have decided to keep it the same length as the primary profile. It is speculated that  this decision was made under the assumption that a profile should not be altered unless specifically stated in ISO specification standards 6 .

NIST Wc and WSm failures
The NIST software was unable to obtain a value for Wc and WSm for any test file, including its own reference data sets. Due to the nature of the calculation of Wc and WSm, and the low amplitude of the waviness profile for many of the test files, it was anticipated that the software packages would struggle to obtain the values for all test files, however, not being able to obtain any is a notable issue. The result is shown in figure 8, where PTB and NPL are shown to obtain values for some files, but NIST obtains none. It should be noted here that it is because of the Wc and WSm failures that there are no results shown for Wc and WSm on any relative parameter value graph for which NIST is the reference NMI.
Upon further research into the implementation of these parameters by NIST, it was found in their 'help' documentation that the height discrimination for the Xc and XSm parameters is defined as a user set percentage of Rz. The ISO 4287 defines the height discrimination to use Xz, e.g. use Wz for Wc/WSm. The description of the height discrimination in the NIST documentation could simply be poorly worded, however, if the documentation truly describes the implementation of the software, the use of Rz instead of Wz could explain the lack of results.
As the waviness profiles have a lower amplitude than the other profiles, if the software were to be using 10% of Rz for the height discrimination instead of Wz, the cut-off height would be higher than the majority of the waviness profiles, leading to a greatly reduced number of profile elements and, therefore, no data from which to calculate the parameters.

NPL waviness parameter failures
Another recurring issue discovered in the NPL results was an inability to obtain waviness parameters for some test files. The test files affected include steps, normrand, Mill, lapping01ms, D_coarse and EDM. An example of some of these files, in particular Mill and normrand, is given in figure 9. It should be mentioned here that for the files for which NPL does obtain waviness parameters, the values are in good agreement with the other NMIs, suggesting the parameter calculation algorithm can work well.
When investigating the outputted .SMD file, the error message 'Missing crossing point in sample lengths' is found next to the failed waviness parameters. Through further investigation with NPL it was discovered that for the waviness profiles that were unable to produce parameter values, a small number of mean line crossing points were present within each sample length. A good example of this is shown in figure 10, where the waviness profiles for the millsim and normrand files are shown. For the millsim dataset, from which the NPL software was able to obtain waviness parameters, at least three crossing points are present for each sampling length. For the normrand dataset, from which the NPL software could not obtain waviness parameters, there are at most two crossing points per sampling length, with one sampling length containing no crossing points.
The information obtained from figure 10 suggests that the NPL software requires a minimum number of mean line crossing points within each sample length to calculate the parameter values. Whether this is the correct approach is up for debate, as an argument can be made that a surface with so few mean line crossing points may not be suitable to calculate parameter values that are meaningful and descriptive of the surface. However, both NIST and PTB were able to calculate waviness parameter values for many of these surfaces, and from their perspective it may be up to the user to decide whether the results obtained are useful.
Regardless of the reasons, the fact that two approaches to handling such surfaces with minimal mean line crossing points exist across different software measurement standards is evidence of ambiguity in the ISO specification standards. 4.5.1. NPL reference file form removal. As discussed above, part of the investigation into the NPL waviness issue was a test to see whether form was present on some of the input files. Form should be removed to ensure that a sufficient number of points cross the mean line to enable the calculation of meaningful waviness parameters. Interestingly, for just two of the seventeen files, form removal had not been performed. The files with form present were millsim and step, both taken from the NPL database. Originally, millsim was one of the files that failed to obtain waviness parameters, however, once form had been removed, the NPL software was successful and obtained results that showed very good agreement with the NIST software.
Upon bringing the issue of two of the files requiring form removal to the attention of NPL, it was discovered that   although the NPL reference software requires a primary profile as input, it is not necessarily the case that the reference datasets match the input requirements of the reference software. While the type F2 reference software was produced by NPL in-house, the type F1 reference data files were produced by the University of Huddersfield. This presents the potential for confusion to users, as it would be assumed by many that the datasets would be ready to work with their associated software. Furthermore, of the ten NPL files tested, only two needed any form removal, suggesting the files are not all given in the same condition.

PTB D_coarse disagreement
One particular file that showed disagreements between PTB and the other two NMIs was the D_coarse file. The results for this file, with NPL as the comparison NMI, are shown in figure 11. PTB shows some disagreement for D_coarse in par ticular for the roughness parameters. The PTB result comes in stark contrast to the relationship between NPL and NIST, which show very good agreement throughout, ignoring the height/spacing parameters. The PTB roughness values do not vary significantly, with the variations being less than 30% of the NPL value, however, the result is interesting when compared to the close agreement that NPL and NIST exhibit.
The reason for these disagreements for PTB is not certain. Noticing the PTB primary parameter values are in agreement with NPL and NIST suggests the act of filtering the profile has some effect in creating the disagreements. It should be noted here that the D_coarse file is one of the shortest profiles tested, so it may be the case that the choice of λ = c 800 μm leads to an insufficient number of sampling points for the PTB software to work well. The D_coarse file also has one of the lowest average spatial frequencies of all the files tested, which could cause some issues with the obtained roughness profile, as there are fewer high spatial frequencies to extract from the profile. The reason the lower Figure 11. Relative difference graph for the D_coarse test file, with NPL as the comparison NMI. NIST shows many parameter values at 1, indicating a good agreement with the NPL value. PTB shows more variation on the roughness parameters.  spatial frequencies would affect PTB differently to the other two NMIs could be due to a difference in filter implementation subtleties, where NPL and NIST may use the same method.

Height/spacing parameter disagreements
As was expected, notable amounts of disagreement between NPL, PTB and NIST were found for the height/spacing parameters, Xc and XSm. As mentioned above, previous work uncovered some ambiguities in the definition of the RSm parameter that led to the potential for different interpretations to obtain different results [18]. As Xc uses the same discrimination methods as XSm, the same issues are expected to apply. Although Leach and Harris' work was carried out in 2002, it appears these definitions are still leading to different results. Examples of the Xc and XSm results are shown in figure 12.
The RSm and Rc parameter results show a tendency for NIST to produce slightly lower values than the other two NMIs. NIST's comparatively lower values are not present on the very periodical, simulated test files such as saw1pad and sin1, suggesting the software's tendency to obtain the lower values is related to the methods employed to determine the profile elements, as the very periodic files are more robust to different profile element calculation methods. It appears that the NIST software uses a different interpretation of the height/ spacing discrimination definitions, causing it to obtain different profile elements to the other two, and hence different values.
In addition, the PSm results, shown in figure 13, show NPL obtaining significantly larger values than NIST and PTB for seven data files. Such an effect is not observed on the roughness parameters, suggesting the application of the filter removes this issue. NPL's tendency to obtain larger values for PSm could, therefore, be related to the extended length of the profile, as there are no end effects to manage so no ends are cut. The details of the effect are unknown, however, it is likely to be related to the discrimination of the profile elements, as this tendency for larger PSm values is not seen for other parameters.

Conclusion
The work described in this paper has sought to identify any potential areas of concern in the current state of profile surface texture parameter calculation. Profile surface texture parameters were calculated for seventeen test files by the reference parameter calculation software on offer from three NMIs: NPL, PTB and NIST. The work has aimed to be inclusive of all stages of the surface texture parameter calculation software, giving focus to the inputs to and implementation of software as well as the results obtained, in the hope to develop a more rounded image of the software packages and facilitate better analysis. Through this more complete approach, it has been found that some differences between the reference software packages are present. These differences in the software are varied, and stem from both differing implementations of the same specification standard, as well as potential errors in the coding of the software. In particular, several conclusions can be made: The main benefit of this work, through the parameter value differences it has uncovered, is a demonstration of the need for tighter definitions in the specification standards. At present, two reference software packages can give different parameter values for the same file, and thus two different results to compare against. This difference in reference software results can lead to differences in values in collaboration projects involving several companies or institutions, causing disagreements for potentially crucial measurements.
In addition, several issues were highlighted during the stages of the project preceding the actual parameter value calcul ation. Problems were encountered when dealing with the .SMD files, in which slightly different formats were leading to input failures. Some of the .SMD difficulties were due to poor formatting of the file or limitations of the software on NIST's side; however, it should be considered that those errors are in part due to the convoluted nature of the .SMD file structure, including outdated control characters which are invisible to the user of any mainstream text editor. It comes as no surprise that both NPL and NIST offer the reference data files in a selection of other data formats, as the .SMD format adds an unnecessary additional layer of complexity to the process. Additionally, the NIST and PTB reference software also accepts different file formats as inputs. It is suggested that the .SMD file format be removed from ISO 5436-2 and replaced by a more robust format which does not require such specific use of control characters. One potential candidate is the .SDF format, which is already used for areal surface texture, making it familiar to many in the industry, and is much more robust, accepting any combination of 〈CR 〉 and 〈LF 〉 to end lines, and ends records simply with a '*' [25]. Another possibility is the .X3P format, an open source data format developed by the 'OpenGPS' consortium [30], currently in use as the default input file-type for the NPL reference software for areal surface texture parameters [31,32], and defined in ISO 25178-72 [33].

Further work
Following this research, there is potential for further analysis of the parameter values to uncover the true causes of the currently unexplained discrepancies in the results. Further analysis will require a collaborative effort with the NMIs to delve into the finer details of the software to identify where the different software packages differ on a more specific level.
Additionally, there is potential to begin work on more refined versions of the current ISO definitions where ambiguities are present. This future work includes the definition of the height/spacing discrimination related to the Xc and XSm parameters in ISO 4287, as well as the definition of the waviness profile in ISO 4288.
The work carried out in this paper has highlighted several problems with using software as a reference standard. Software will often exhibit errors due to implementation approximations, and excluding the case where a surface texture parameter is defined with an algorithm instead of an equation, will never be able to reliably obtain a true value. Further work is planned that will move away from the use of reference software and discrete reference data and begin development of new mathematical reference standards. These are planned to comprise of mathematical functions that can operate on mathematically produced type F1 measurement standards to obtain a reference value, and are traceable back to the definitions of surface texture parameters given in the ISO specification standards. Using mathematical reference standards avoids the need for discrete reference data, which is an approximation of a surface, and allows true reference parameter values to be produced. From a mathematical description of a surface, one can generate a discrete surface profile data set with given implementation parameters such as number of points or lateral spacing, perform a parameter calculation on the data set, and compare the result with the theoretical value given by the mathematical description. Such an approach allows for an accurate parameter value to be known, whilst still allowing users to perform parameter calculations on discrete data sets using their existing methods and compare directly with the true reference value.