Metrology and theory of measurement

Tai ngay!!! Ban co the xoa dong chu nay!!! De Gruyter Studies in Mathematical Physics 20 Editors Michael Efroimsky, Bethesda, USA Leonard Gamberg, Reading, USA Dmitry Gitman, São Paulo, Brasil Alexander Lazarian, Madison, USA Boris Smirnov, Moscow, Russia Valery A Slaev Anna G Chunovkina Leonid A Mironovsky Metrology and Theory of Measurement De Gruyter Physics and Astronomy Classification Scheme 2010: 06.20.-f, 06.20.F-, 06.20.fb, 03.65.Ta, 06.30.-k, 07.05.Rm, 07.05.Kf, 85.70.Kh, 85.70.Li ISBN 978-3-11-028473-7 e-ISBN 978-3-11-028482-9 ISSN 2194-3532 Library of Congress Cataloging-in-Publication Data A CIP catalog record for this book has been applied for at the Library of Congress Bibliographic information published by the Deutsche Nationalbibliothek The Deutsche Nationalbibliothek lists this publication in the Deutsche Nationalbibliografie; detailed bibliographic data are available in the Internet at http://dnb.dnb.de © 2013 Walter de Gruyter GmbH, Berlin/Boston Typesetting: P T P-Berlin Protago-TEX-Production GmbH, www.ptp-berlin.de Printing and binding: Hubert & Co GmbH & Co KG, Göttingen Printed on acid-free paper Printed in Germany www.degruyter.com “To measure is to know.” Lord Kelvin “We should measure what is measurable and make measurable what is not as such.” Galileo Galilei “Science begins when they begin to measure ” “Exact science is inconceivable without a measure.” D.I Mendeleyev “ for some subjects adds value only an exact match to a certain pattern These include weights and measures, and if the country has several well-tested standards of weights and measures it indicates the presence of laws regulating the business relationship in accordance with national standards.” J.K Maxwell Preface During the 125th anniversary of the Metre Convention in 2000, Steve Chu, now President Obama’s Energy Secretary and a one-time metrologist, spoke and included the now famous quotation: “Accurate measurement is at the heart of physics, and in my experience new physics begins at the next decimal place” Metrology, as the science of measures or measurements traceable to measurement standards [323], operates with one of the most productive concepts, i.e., with the concept of measurement accuracy, which is used without exception in all natural and technical sciences, as well as in some fields of social sciences and liberal arts Metrology, by its structure, can be considered a “vertically” designed knowledge system, since at the top level of research it directly adjoins the philosophy of natural sciences, at the average level it acts as an independent section of the natural (exact) sciences, and at the bottom level it provides the use of natural science achievements for finding solutions to particular measurement tasks, i.e it performs functions of the technical sciences In such a combination, it covers a range from the level of a knowledge validity criterion to the criterion of correctness in the process of the exchange of material assets For metrology the key problem is to obtain knowledge of physical reality, which is considered through a prism of an assemblage of quantity properties describing the objectively real world In this connection, one of the fundamental tasks of metrology is the development of theoretical and methodological aspects of the procedure of getting accurate knowledge relating to objects and processes of the surrounding world which are connected with an increase in the measurement accuracy as a whole Metrology, as the most universal and concentrated form of an organizing purposeful experience, allows us to make reliability checks of the most general and abstract models of the real world (owing to the fact that a measurement is the sole procedure for realizing the principle of observability) Metrology solves a number of problems, in common in a definite sense with those of the natural sciences, when they are connected with a procedure of measurement:  the problem of language, i.e the formalization and interpretation of measurement results at a level of uniformity;  the problem of structuring, which defines the kind of data which should be used depending on the type of measurement problem being solved, and relates to a system approach to the process of measurements; viii Preface  the problem of standardization, i.e determination of the conditions under which the accuracy and correctness of a measurement result will be assured;  the problem of evaluating the accuracy and reliability of measurement information in various situations At present, due to the development of information technologies and intelligent measurement systems and instruments, as well as the growing use of mathematical methods in social and biological sciences and in the liberal arts, there were a number of attempts to expand the interpretation of metrology [451] not only as the science about measurements of physical quantities, but also as a constituent of “gnoseo-techniques”, information science, “informology” and so on, the main task of which is "to construct and transmit generally recognized scales for quantities of any nature", including those which are not physical Therefore, it remains still important to determine the place of metrology in the system of sciences and its application domain more promptly, i.e., its main directions and divisions [9, 228, 429, 451, 454, 503, 506, and others] It is possible to analyze the interconnection of metrology and other sciences from the point of view of their interaction and their mutual usefulness and complementariness, using as a basis only its theoretical fundamentals and taking into account a generally accepted classification of sciences in the form of a “triangle” with vertexes corresponding to the philosophical, natural, and social sciences [257], but paying no attention to its legislative, applied, and organizational branches Among such sciences one can mark out philosophy, mathematics, physics, and technical sciences, as well as those divisions of the above sciences, the results of which are actively used in theoretical metrology, and the latter, in its turn, provides them with materials to be interpreted and given a meaning to It is known that in an application domain of the theoretical metrology two main subdivisions can be singled out: the general theory of measurements and the theory of measurement assurance and traceability The general theory of measurements includes the following directions:   original regulations, concepts, principles, postulates, axiomatic, methodology, terms, and their definitions; simulation and investigation of objects, conditions, means, and methods of performing measurements;  theory of scales, measures, metrics, references, and norms;   theory of measurement transformation and transducers; theory of recognition, identification, estimation of observations, and data processing; theory of measurement result uncertainties and errors;  theory of dynamic measurements and signal restoration;  Preface ix  theory of enhancement of the measurement accuracy, sensitivity, and ultimate capabilities taking into account quantum and other limitations;  automation and intellectualization of measurement information technologies, interpretation and use of measurement information in the process of preparing to make decisions;  theory of the optimal planning for a measurement experiment; theory of metrology systems; theory of measurement quality estimation, as well as of technical and social-economic efficiency of metrology and measurement activities   The theory of measurement assurance and traceability consists of the following directions:    theory of physical quantities units, systems of units, and dimensionality analysis; theory of measurement standards; theory of reproducing, maintaining, and transferring a size of quantity units;  theory of estimating normalized metrological characteristics of measuring instruments;  methodology of performing metrology procedures; theory of metrological reliability and estimation of intercalibration (interverification) intervals;   theory of estimating the quality of metrology systems, and the methodology of optimizing and forecasting their development Let the particular features of measurement procedures be considered in the following order: interaction of an object with a measuring instrument ! recognition and selection of a measurement information signal ! transformation ! comparison with a measure ! representation of measurement results Interaction of an object under investigation with a measuring instrument assumes searching, detecting, and receiving (reception) a quantity under measurement, as well as, if necessary, some preparatory procedures of the probe-selection or probe preparation type, or exposure of the object to some outside influence for getting a response (stimulation), determining an orientation and localization in space and time Discrimination or selection assume marking out just that property of an object to which the quantity under measurement corresponds, including marking out a useful signal against a noise background and applying methods and means for noise control Transformation includes changes of the physical nature of an information carrier or of its form (amplification, attenuation, modulation, manipulation, discretization and quantization, analog-digital and digital-analog conversion, coding and decoding, etc.), as well as the transmission of measurement information signals over communication 484 Chapter Validation of software used in metrology loading without being activated, because it must be possible to discard the loaded software and revert to the old version, if the checks fail (2) In the case of a verified update, the software may also be loaded and temporarily stored before installation, but, depending on the technical solution, loading and installation may also be accomplished in one step (3) Here, only failure of the verification due to the software update is considered Failure due to other reasons does not require reloading and reinstalling of the software, symbolized by the NO-branch The relevant OIML recommendation may require the setting of certain devicespecific parameters available to the user In such a case, the measuring instrument must be fitted with a facility to automatically and nonerasably record any adjustment of the device-specific parameter, e.g., an audit trail The instrument must be able to present the recorded data Note: An event counter is not an acceptable solution The traceability means and records are part of the legally relevant software and should be protected as such The software employed for displaying the audit trail belongs to the fixed legally relevant software 6.4.3 Software validation methods 6.4.3.1 Overview of methods and their application Selection and sequence of the methods given below (see Table 6.5) are not strongly assigned and may change in the procedure of validation from time to time 6.4.3.2 Description of selected validation methods Analysis of documentation, specification, and validation of the design (AD) Application: This is the basic procedure which has to be applied in any case Preconditions: The procedure is based on the manufacturer’s documentation of the measuring instrument Depending on the demands this documentation must have an adequate scope (1) Specification of the externally accessible functions of the instrument in a general form (suitable for simple instruments with no interfaces except a display, all features verifiable by functional testing, low risk of fraud); (2) Specification of software functions and interfaces (necessary for instruments with interfaces and for instrument functions that cannot be functionally tested and in case of increased risk of fraud) The description must make evident and explain all software functions which could have an impact on metrological features; Validation by functional testing of metrological functions Validation by functional testing of software functions Metrological data flow analysis Code inspection and walkthrough Software module testing VFTM VFTSw DFA CIWT SMT All purposes when input and output can clearly be defined All purposes Software separation, evaluation of the impact of commands on the instrument’s functions Correct functioning of communication, indication, fraud protection, protection against operating errors, protection of parameters, fault detection Knowledge of programming languages Instruction for the method necessary Source code, common software tool (simple procedure), tools (sophisticated procedure) Source code, testing environment, special software tools Knowledge of programming languages, protocols, and other IT issues Instruction for using the tools necessary Knowledge of programming languages, protocols, and other IT issues — Documentation, common software tool Source code, common software tool — Special skills for performing Documentation Documentation Always Correctness of the algorithms, uncertainty, compensating and correcting algorithms, rules for price calculation Preconditions, tools for application Application Note:: Text editors, hexadecimal editors, etc are considered as “common software tools” Analysis of the documentation and validation of the design Description AD Abbreviation Table 6.5 Overview of the proposed selected validation methods Section 6.4 Requirements for software and methods for its validation 485 486 Chapter Validation of software used in metrology (3) Regarding interfaces, the documentation must include a complete list of commands or signals which the software is able to interpret The effect of each command must be documented in detail The way in which the instrument reacts to undocumented commands must be described; (4) Additional documentation of the software for complex measuring algorithms, cryptographic functions, or crucial timing constraints must be provided, if this is necessary for understanding and evaluating the software functions; (5) When it is not clear how to validate a function of a software program, the burden of developing a test method is placed on the manufacturer In addition, the services of the programmer should be made available to the examiner for the purposes of answering questions A general precondition for examination is the completeness of the documentation and the clear identification of the EUT, i.e., of the software packages contributing to the metrological functions Description: The examiner evaluates the functions and features of the measuring instrument using the verbal description and graphical representations and decides whether or not they comply with the requirements of the relevant OIML recommendation Metrological requirements as well as software-functional requirements (e.g., fraud protection, protection of adjustment parameters, nonallowed functions, communication with other devices, update of software, fault detection, etc.) must be considered and evaluated Result: The procedure gives a result for all the characteristics of the measuring instrument, provided that the appropriate documentation has been submitted by the manufacturer The result should be documented in a section related to software in a software evaluation report included in the evaluation report format of the relevant OIML recommendation Complementary procedures: Additional procedures should be applied, if examining the documentation cannot provide substantiated validation results In most cases validating the metrological functions by functional testing is a complementary procedure References: FDA, Guidance for FDA Reviewers and Industry Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, 29 May 1998; IEC 61508-7, 2000-3 Section 6.4 Requirements for software and methods for its validation 487 Validation by functional testing of the metrological functions (VFTM) Application: Correctness of algorithms for calculating the measurement value from raw data, for linearization of a characteristic, compensation of environmental influences, rounding in price calculation, etc Preconditions: Operating manual, functioning pattern, metrological references and test equipment Description: Most of the approval and test methods described in the OIML recommendations are based on reference measurements under various conditions Their application is not restricted to a certain technology of the instrument Although it does not aim primarily at validating the software, the test result can be interpreted as a validation of some software parts, in general even the metrologically most important ones If the tests described in the relevant OIML recommendation cover all the metrologically relevant features of the instrument, the corresponding software parts can be regarded as being validated In general, no additional software analysis or test has to be applied to validate the metrological features of the measuring instrument Result: Correctness of algorithms is valid or invalid Measurement values under all conditions are or are not within the MPE Complementary procedures: The method is normally an enhancement of the predecessor one In certain cases it may be easier or more effective to combine the method with examinations based on the source code or by simulating input signals e.g., for dynamic measurements References: Various specific OIML recommendations Validation by functional testing of the software functions (VFTSw) Application: Validation of e.g., the protection of parameters, indication of a software identification, software supported fault detection, configuration of the system (especially of the software environment), etc Preconditions: Operating manual, software documentation, functioning pattern, test equipment Description: Required features described in the operating manual, instrument documentation or software documentation are checked practically If they are software controlled, they are to be regarded as validated if they function correctly without any further software analysis Features addressed here are, e.g.,:  normal operation of the instrument, if its operation is software controlled All switches or keys and described combinations should be employed and the reaction of the instrument evaluated In graphical user interfaces, all menus and other graphical elements should be activated and checked; 488 Chapter Validation of software used in metrology  effectiveness of parameter protection can be checked by activating the protection means and trying to change a parameter;  effectiveness of the protection of stored data can be checked by changing some data in the file and then checking whether this is detected by the program;  generation and indication of the software identification can be validated by practical checking; if fault detection is software supported, the relevant software parts can be validated by provoking, implementing, or simulating a fault and checking the correct reaction of the instrument; if the configuration or environment of the legally relevant software is claimed to be fixed, protection means can be checked by making unauthorized changes The software should inhibit these changes or should cease to function   Result: Software controlled feature under consideration is or is not OK Complementary procedures: Some features or functions of a software controlled instrument cannot be practically validated as described If the instrument has interfaces, it is in general not possible to detect unauthorized commands only by trying commands at random Besides this, a sender is needed to generate these commands For normal validation the level method AD, including a declaration by the manufacturer, can cover this requirement For an extended examination level, a software analysis such as DFA or CIWT is necessary References: FDA Guidance for Industry Part 11, August 2003; WELMEC Guide 2.3; WELMEC Guide 7.2 Metrological dataflow analysis (DFA) Application: Construction of the flow of measurement values through the data domains subject to legal control Examination of software separation Preconditions: Software documentation, source code, editor, text search program, or special tools Knowledge of programming languages Description: It is the aim of this method to find all parts of the software which are involved in the calculation of the measurement value or which may have an impact on it Starting from the hardware port where measurement raw data from the sensor is available, the subroutine which reads them is searched This subroutine will store them in a variable after possibly having done some calculations From this variable the intermediate value is read by another subroutine and so forth until the completed measurement value is output to the display All variables used as storage for intermediate measurement values and all subroutines transporting these values can be found in the source code simply by using a text editor and a text search program to find the variable or subroutine names in another source code file than the one currently open in the Section 6.4 Requirements for software and methods for its validation 489 text editor Other data flows can be found by this method, e.g., from interfaces to the interpreter of received commands Furthermore circumvention of a software interface can be detected Result: This can be validated whether software separation is OK or not OK Complementary procedures: This method is recommended if software separation is realized and if high conformity or strong protection against manipulation is required It is an enhancement to AD through VFTSw and to CIWT Reference: IEC 61131-3 Code inspection and walk-through (CIWT) Application: Any feature of the software may be validated with this method if enhanced examination intensity is necessary Preconditions: Source code, text editor, tools Knowledge of programming languages Description: The examiner walks through the source code assignment by assignment, evaluating the respective part of the code to determine whether or not the requirements are fulfilled and whether or not the program functions and features are in compliance with the documentation The examiner may also concentrate on algorithms or functions which he has identified as complex, error-prone, insufficiently documented, etc and inspect the respective part of the source code by analyzing and checking it Prior to these examination steps the examiner will have identified the legally relevant software part, e.g., by applying metrological data flow analysis In general, code inspection or walk-through is limited to this part By combining both methods, the examination effort is minimal compared to the application of these methods in the normal software production with the objective of producing failure-free programs or optimizing performance Result: Implementation compatible with the software documentation and in compliance or not in compliance with the requirements Complementary procedures: This is an enhanced method, additional to AD and DFA Normally it is only applied in spot checks Reference: IEC 61508-7:2000-3 Software module testing (SMT) Application: Only if high conformity and protection against fraud is required This method is applied when functions of a program cannot be examined exclusively on the basis of written information It is appropriate and economically advantageous for validation of dynamic measurement algorithms 490 Chapter Validation of software used in metrology Preconditions: Source code, development tools (at least a compiler), functioning environment of the software module under test, input data set and corresponding correct reference output data set or tools for automation Skills in IT, knowledge of programming languages Cooperation with the programmer of the module being tested is advisable Description: The software module being tested is integrated in a test environment, i.e., a specific test program module which calls the module under test and provides it with all necessary input data The test program receives output data from the module under test and compares it with the expected reference values Result: Measuring algorithm or other tested functions are correct or not correct Complementary procedures: This is an enhanced method, additional to VFTM or CIWT It is only profitable in exceptional cases Reference: IEC 61508-7:2000–3 6.4.3.3 Validation procedure A validation procedure consists of a combination of analysis methods and tests The relevant OIML recommendation may specify details concerning the validation procedure, including: (a) which of the validation methods described in Section 6.4.3 must be carried out for the requirement under consideration; (b) how the evaluation of test results must be performed; (c) which result is to be included in the test report and which is to be integrated in the test certificate In Table 6.6 two alternative levels, A and B, for validation procedures are defined Level B implies an extended examination, compared to A The choice of the A- or B-type validation procedures may be made in the relevant OIML recommendation – different or equal for each requirement, in accordance with the expected     risk of fraud; area of application; required conformity to the approved type; risk of wrong measurement result due to operating errors 6.4.3.4 Equipment being tested Normally, tests are carried out on the complete measuring instrument (functional testing) If the size or configuration of the measuring instrument does not lend itself to testing as a whole unit, or if only a separate device (module) of the measuring instru- 491 Section 6.4 Requirements for software and methods for its validation Table 6.6 Recommendations for combinations of analysis and test methods for the various software requirements (acronyms defined in Table 6.5) Requirement Software identification Correctness of algorithms and functions Validation procedure A (normal examination level) AD + VFTSw AD + VFTM Validation procedure B (extended examination level) AD + VFTSw + CIWT Comment Select “B” if high conformity is required AD + VFTM + CIWT/SMT Software protection Prevention of misuse AD + VFTSw AD + VFTSw Fraud protection AD + VFTSw AD+VFTSw + Select “B” in case of DFA/CIWT/SMT high risk of fraud Support of hardware features Support of fault AD + VFTSw AD + VFTSw + Select “B” if high detection CIWT + SMT reliability is required Support of durability AD + VFTSw AD+VFTSw+CIWT+ Select “B” if high protection SMT reliability is required Specifying and separating relevant parts and specifying interfaces of parts Separation of elecAD AD tronic devices and sub-assemblies Separation of softAD AD + DFA/CIWT ware parts Shared indications AD + VFTM/VFTSw AD + VFTM/VFTSw + DFA/CIWT Storage of data, AD + VFTSw AD + VFTSw + Select “B” if transtransmission via CIWT/SMT mission of measurecommunication ment data in open systems system is foreseen The measurement AD + VFTSw AD + VFTSw + Select “B” in case of value stored or CIWT/SMT high risk transmitted must be accompanied by all relevant information necessary for future legally relevant use The data must be AD + VFTSw / protected by software means to guarantee authenticity, integrity and, if necessary correctness of the information of the time of measurement For a high protection / AD + VFTSw + SMT level it is necessary to apply cryptographic methods 492 Chapter Validation of software used in metrology Table 6.6 (cont.) Requirement Validation procedure A (normal examination level) AD + VFTSw AD + VFTSw Validation procedure B (extended examination level) AD + VFTSw + SMT AD + VFTSw + SMT Transmission interruption AD + VFTSw AD + VFTSw + SMT Time stamp Compatibility of operating systems and hardware, portability AD + VFTSw AD + VFTSw AD + VFTSw + SMT AD+VFTSw+SMT Automatic storing Transmission delay Verified Update Traced Update Maintenance and re-configuration AD AD AD + VFTSw AD + VFTSw + CIWT/SMT Comment Select “B” in the case of high risk of fraud, e.g transmission in open systems Select “B” in the case of high risk of fraud, e.g transmission in open systems Select “B” in the case of high risk of fraud ment is concerned, the relevant OIML recommendation may indicate that the tests, or certain tests, must be carried out on the electronic devices or software modules separately, provided that, in the case of tests with the devices in operation, these devices are included in a simulated setup sufficiently representative of its normal operation The approval applicant is responsible for the provision of all the required equipment and components 6.5 Type approval 6.5.1 Documentation for type approval For type approval the manufacturer of the measuring instrument must declare and document all program functions, relevant data structures, and software interfaces of the legally relevant software part implemented in the instrument No hidden undocumented functions are permitted to exist The commands and their effects must be completely described in the software documentation submitted for type approval The manufacturer must state the completeness of the documentation of the commands If the commands can be entered via a user interface, they must be completely described in the software documentation submitted for the type approval Section 6.5 Type approval 493 Furthermore, the application for type approval must be accompanied by a document or other evidence supporting the assumption that the design and characteristics of the software of the measuring instrument comply with the requirements of the relevant OIML recommendation, in which the general requirements of this document have been incorporated 6.5.1.1 Typical documentation Typical documentation (for each measuring instrument, electronic device, or subassembly) basically includes:  a description of the legally relevant software and how the requirements are met: – list of software modules belonging to the legally relevant part, including a declaration that all legally relevant functions are included in the description; – description of the software interfaces of the legally relevant software part and of the commands and data flows via this interface, including a statement of completeness; – description of the generation of the software identification; – depending on the validation method chosen in the relevant OIML recommendation, the source code must be made available to the testing authority if high conformity or strong protection is required by the relevant OIML recommendation; – list of parameters to be protected and description of the means for protection;  a description of the suitable system configuration and minimum required resources;  a description of security means of the operating system (password, etc if applicable); a description of the (software) sealing method(s); an overview of the system hardware, e.g., topology block diagram, type of computer(s), type of network, etc Where a hardware component is deemed legally relevant or where it performs legally relevant functions, this should also be identified; a description of the accuracy of the algorithms (e.g., filtering of A/D conversion results, price calculation, rounding algorithms, etc.);      a description of the user interface, menus, and dialogues; the software identification and instructions for obtaining it from an instrument in use;  list of commands of each hardware interface of the measuring instrument/electronic device/sub-assembly including a statement of completeness;  list of durability errors detected by the software, and if necessary for understanding, a description of the detecting algorithms;  a description of data sets stored or transmitted; 494 Chapter Validation of software used in metrology  if fault detection is realized in the software, a list of faults which are detected and a description of the detecting algorithm;  the operating manual 6.5.2 Requirements for the approval procedure Test procedures in the framework of the type approval, e.g., those described in OIML D 11:2004, are based on well-defined test setups and test conditions and can rely on precise comparative measurements “Testing” and “validating” software are different activities The accuracy or correctness of software in general cannot be measured in a metrological sense, although there are standards which prescribe how to “measure” software quality (e.g., ISO/IEC 14598) The procedures described here take into consideration both the legal metrology needs and also well-known validation and test methods in software engineering, but which not have the same goals (e.g., a software developer who searches for errors but who also optimizes performance) As shown in Section 6.5.4 each software requirement needs individual adaptation of suitable validation procedures The effort for the procedure should reflect the importance of the requirement in terms of accuracy, reliability and protection against corruption The aim is to validate the fact that the instrument to be approved complies with the requirements of the relevant OIML recommendation For software-controlled instruments the validation procedure comprises examinations, analysis, and tests and the relevant OIML recommendation are to include an appropriate selection of the methods described below The methods described below focus on the type examination Verifications of every single instrument in use in a particular field are not covered by those validation methods: see Section 6.5.3 (Verification) for more information The methods specified for software validation are described in Section 6.4.3 Combinations of these methods forming a complete validation procedure adapted to all requirements defined in Section 6.4.1 are specified in Section 6.4.5 6.5.3 Verification If metrological control of measuring instruments is required in a country, there must be a means to check in the field during operation the identity of the software, the validity of the adjustment, and the conformity to the approved type The relevant OIML recommendation may require carrying out the verification of the software in one or more stages, according to the nature of the considered measuring instrument Verification of a software must include:  an examination of the conformity of the software with the approved version (e.g., verification of the version number and checksum); Section 6.6 Assessment of severity (risk) levels 495  an test whether the configuration is compatible with the declared minimum configuration, if given in the approval certificate;  a test whether the inputs/outputs of the measuring instrument are well configured in the software when their assignment is a device-specific parameter;  a test whether the device-specific parameters (especially the adjustment parameters) are correct 6.6 6.6.1 Assessment of severity (risk) levels Brief review By now a number of various approaches to the assessment of severity (risk) levels, extent of test rigidity, as well as to the selection of risk classes have been formed They not principally contradict each other The first approach set forth in a OIML document [181], uses only two such levels:   (I) normal level of protection against falsification, as well as a level of confirming the compliance, reliability, and kind of measurement; (II) increased level of the seriousness of errors with enhanced countermeasures The second approach, indicated in the WELMEC Guide [541], assigns six risk classes for measuring instruments: A, B, C, D, E, and F However, at present only three classes are normally applied: B, C, and D (“low”, “middle” and “high”), and only in rare cases is the class E applied Two risk classes, A and F, are left as “just in case”, “in reserve”, for an unexplored future time The third approach, adopted in Russia, operates with three degrees of severity of software tests: low, middle, and high Despite the difference in the terminology these approaches appear to be close to each other to a rather sufficient extent Difference in understanding arises first of all, when answering the question: “Who has the right and duty to establish the mentioned levels of error seriousness, risk classes, and degrees of the severity of tests?” However, it should be noted that, according to information mentioned in Section 6.2.2, the PTB and NPL representatives [1] propose the procedure of assessing risks based on ISO/IEC 16085 [233] and ISO/IEC 27005 [235], using the widely recognized approach for determining categories of risk (factors and level of risks) and facilities for minimizing them The essence of these proposals is explained below The algorithm of risk control related to [235], is illustrated in Figure 6.6 The requirements for measurement software must have information for enable  determination of the category of risk on the basis of factors of risk specific for such a software with acceptable risk levels; 496 Chapter Validation of software used in metrology Context establishment Risk estimation Risk analysis Risk identification Risk estimation Risk calculation Decision point for risks No Is estimation satisfactory? No Risk acceptance End of the first and the following iterations Yes Risk treatment Decision point for risks No No Accept risks? Yes Figure 6.6 Control of risks related to standard ISO/IEC 27005    provision of each category of risk with characteristics which would point to measurement software; factors of risk must be traced to unified indices of risk, namely the Indices of measurement software (IMS); indication of each category of risk (IMS), what technical facilities must be used, as well as what level of activity there has to be for each process of a life cycle of software Section 6.6 Assessment of severity (risk) levels 497 For categories of risk we distinguish:  factors of risk, limited by three: the complexity level of control, level of calculation complexity, level of system integrity (undamaged state, safety and influence of environment) If necessary, they can be expanded to aspects specific for other fields;  levels of risk supposed to limit the number of risk levels for each base factor of risk to four) Characteristics for categories of risk To determine a corresponding risk category of software, it is necessary to mark measurement-oriented characteristics for each factor of risk and for each level of risk Examples of the risk factor “complexity of control”: influence of software control functions on measurement processes; software influence on measurement results; amount and complexity of the software interaction with other software/hardware subsystems To create the procedure of risk control, the risk factors are traced to risk indices, i.e., to IMS In accordance with a technical supposition the number of risk levels for basic IMS is limited to five (from to 4) Recommended facilities The development guide which the authors recommend in [1] must provide technical devices and requirements acceptable for the process which are intended to be used for the corresponding IMS levels of each of selected processes of the life cycle A list of acceptable hardware for practical development and evaluation as well as for estimates of samples selected needs to be elaborated Indices of measurement software are illustrated in Table 6.7 Technique recommended for designing is illustrated in Table 6.8 Essential processes of programming includes: analysis of requirements, software design, software application, software test, maintenance of software in a healthy state When developing risk estimates, the following must be done: factors of risk and appropriate levels of risk, selection of a set of measurement software-oriented characteristics for each level of risk class/level, development of suggestions relative to IMS levels for all categories of risk, development of rules for designating technique that should be used for the appropriate IMS levels An approach of this type is being presently being developed Therefore, in what follows the approaches considered in documents [181, 541] will be examined in more detail 6.6.2 Assessment of severity (risk) levels according to OIML Document D 31 This section is intended as a guide for determining a set of severity levels to be generally applied for tests carried out on electronic measuring instruments It is not intended 498 Chapter Validation of software used in metrology Table 6.7 Indices of measurement software System integrity Calculation complexity Very low (VL) VL L H VH Low (L) VL L H VH High (H) VL L H VH Very high (VH) VL L H VH Complexity of control VL L H VH ? ? ? ? Table 6.8 Technique recommended for designing Technique Modeling of data flow Levels of IMS  Modeling control of data flow  Relation of essences   Unified language of modeling Z-communications  Transfers of states  Petri net  as a classification with strict limits leading to special requirements as in the case of an accuracy classification Moreover, this guide does not restrict technical committees and subcommittees from providing severity levels which differ from those from the guidelines set forth in this