Enabling the use of digital calibration certificates in industrial calibration management systems

Metrology has been a slowly digitalizing field in which a significant part of the handling of data has been dependent on paper-based processes. Due to the need for the improved efficiency and reliability of these processes, digitalization has become a major topic of interest in the metrology community. Data formats such as the digital calibration certificate (DCC) have an essential role as an enabler of further digitalization, acting as the harmonized data format for calibration data. Naturally, introducing these data formats into industrial usage sets new requirements with respect to the calibration management and associated systems. Diversity of metrology also means that the systems need to be flexible and scalable to fulfill the needs of actors in the global calibration infrastructure with very different requirements. This paper presents a conceptual approach for enhancing the communications between the existing systems in a calibration ecosystem and enabling DCC-based data exchange with third-party systems using the Beamex calibration ecosystem as an example. Thus, the presented system architecture concept that introduces data and DCC exchange services would provide a solution to enable the use of DCCs on Beamex systems.

1 Introduction

Metrology provides an essential framework that is needed for the quality management of products and services. Hence, the global metrology infrastructure has been established to ensure the consistency of measurements across the world. A key element to ensuring the comparability of measurements taken at different times in different locations by different organizations is the fact that the measurements are traceable to the same measurement standards; this is established via unbroken chains of calibration. Conventionally, the calibration processes and the associated data exchange has been bilateral, closed-loop communication between the calibration service providers and customers (Nummiluikki et al., 2021). From a business perspective, this kind of approach has its benefits in the form of close relationships that are important in ensuring, for example, that the services fulfill any specific requirements the customer may have. Figure 1 presents the bilateral communication between the customer and the different actors in their calibration ecosystem.

Figure 1 Bilateral communication between an instrument owner and different actors of the calibration ecosystem.

Especially for larger companies operating in different regions globally, the number of individual service providers can be very high, as instrument manufacturers, system providers, and service providers typically focus on particular quantities, measurement technologies, or procedures. Similarly, the service providers or the other actors in the calibration ecosystem also have their own networks of actors with whom they communicate. As a result, managing calibrations quickly becomes increasingly complex, as the number of measured quantities, individual instruments, and related service providers increases, even though there are plenty of calibration-related standards and guidelines in place. For example, the operation of accredited calibration laboratories is regulated, with accreditation based on standards and agreements (e.g., the ISO/IEC 17025 standard, which also specifically defines the information that must be included in calibration certificates), but there can be many seemingly minor differences in the ways of presenting data. Consequently, this means that the handling of the data requires human interpretation and a significant amount of subject matter expertise, as automating the data processing could, in the worst case, require a customized solution for each communication.

Figure 2 presents an example of a calibration process based on conventional bilateral communication between the instrument owner and calibration provider. The example corresponds to a case in which the instrument owner and calibration provider are using email or other conventional communication channels to exchange the data in a format that is not directly usable in the systems used by the sender or receiver, such as a PDF file. This means that the process will not be as efficient as possible and that the integrity of the data is compromised, as the data entries need to be done manually, leading to the possibility of errors.

Figure 2 A simplified example of a conventional calibration process.

Overall, streamlining these processes through the harmonization and digitalization of calibration data management can offer significant benefits in terms of efficiency and reduced costs. Combined with the rapid progress in digitalization in other sectors, a need for improvement is the reason that digitalization has become a highly prioritized research topic in the metrology community (Heeren et al., 2021). An essential part of these digitalization efforts is establishing standardized formats for metrological data, such as digital calibration certificates (DCCs), that will enable the machine-readability and machine-processability of metrological data (Engel, 2023; Kuster, 2023; Hackel et al., 2021). The DCC is intended as a framework for the exchange of calibration data within the metrology infrastructure, thereby enabling further digitalization of calibration-related processes (Hackel et al., 2023). As the metrology infrastructure is strongly based on mutual trust between the organizations, an important part of the digitalization process is extending this trust into digital applications (Brown et al., 2020). For this purpose, different types of cryptographic methods such as digital signatures or distributed ledgers can be used (Hackel et al., 2021; Fay, 2023; Mustapää et al., 2022; Schaerer and Braun, 2022).

The need for harmonization sets a lot of requirements for individual organizations with respect to adapting to changes in their business environment. One way to ease harmonization and adaptation to the use of the DCC is establishing a platform-based ecosystem, as the way the metrology infrastructure is formulated is a typical scenario in which a platform-based economy could provide significant benefits because the development costs could be shared between collaborators (Nummiluikki et al., 2021). Examples describing such an approach have been presented in publications such as Bruns et al. (2021), Mustapää et al. (2022), Riska (2022), and Nummiluikki et al. (2023). Figure 3 presents an example of how platform-based communication could be organized within the calibration ecosystem.

Figure 3 Communication between the different actors in a platform-based calibration ecosystem.

Compared with the bilateral communication in Fig. 1, the platform allows more efficient sharing of data between the actors if that is deemed beneficial. In terms of the confidentiality of the communications, the platform-based communication does not differ from the bilateral communication, as the sharing of the data does not have to be public.

Although, a DCC-based data exchange platform as a concept can be considered to be a feasible approach for organizing the exchange of calibration-related data between organizations, there are still some practical system-level issues that have to be solved before the DCCs can be made widely available. Examples of such issues include the integration of existing systems into the third-party systems used by customers or service providers, depending on the role of the organization. A fundamental difference between closed and open systems is that enabling open communication sets new requirements for securing the systems and the associated data being exchanged.

Figure 4 presents a generic example of a calibration process when a platform is used for the communication and validation of the exchanged data. The main difference between this approach and the conventional approach is that the platform-based approach allows for the processing of the data without compromising the data integrity while also improving efficiency.

Figure 4 An example of a platform-based calibration process.

Enabling smooth communication between the different types of systems is made more challenging due to the different use cases and environments in which the systems have been designed to function. For example, the communicating calibration equipment intended for the on-site calibration of process instruments must be usable in environments where no network connection is available; thus, establishing communication between the calibrators and calibration management systems in a way that would require a continuous connection to a network is not viable. For example, in the Beamex calibration ecosystem, communication between different systems is channeled through a separate data exchange service that enables communication between different systems asynchronously. This kind of approach is also suitable for implementations enabling the use of DCCs, as it introduces flexibility in the DCC-based data exchange between different organizations.

In this paper, we present the approach taken to enable the exchange of data between different systems to support the formulation of broader DCC-based calibration ecosystems. The following sections of this publication are structured as follows: Sect. 2 describes the requirements that were defined for the data exchange and DCC services, based on which the design system architecture and the applicable technologies were evaluated; Sect. 3 presents the resulting concept defined based on the requirement specifications and technology evaluation; Sect. 4 evaluates the presented concept and its limitations in terms of its original design criteria and implementation considering its eventual use cases; and Sect. 5 concludes the paper by summarizing the key findings.

2 Design requirements

Decision-making regarding the ideal approach for designing the data exchange service was done based on a feasibility study in which the alternative approaches were evaluated. The feasibility study included the definition of the criteria for the system architecture based on the technologies used in the existing systems, the intended use cases, and other requirements set by standards or regulations. The systems with which the data exchange service needs to work to enable the use of DCCs include the following:

• a calibration management system that has been intended for on-premises use (CMX);

• a cloud-based calibration management system (LOGiCAL);

• third-party calibration and calibration management systems, e.g., a customized software used at a service provider's calibration laboratory; and

• calibrators and mobile device applications used for documenting calibrations (bMobile).

Prior to the data exchange service, communication from the calibration management systems to the calibration devices was implemented in two different ways, which the presented approach aimed to replace in most applications. Enabling communication between third-party systems basically requires that an open interface is established in a way that is already considered to be an industry standard. In this kind of application, the common standard is an application programming interface (API) based on a representational state transfer (REST) framework, typically referred to as a REST API.

Requirements with respect to data storage included that the data stored and transferred were both structured, e.g., DCCs and metadata on the calibration results, and unstructured, e.g., measurement results from calibrations, data. However, more specific requirements for the data storage came from the regulations on the industries in which the intended end users will operate. For example, in the pharmaceutical industry, data integrity is considered to be very important; thus, there are strict regulations on the management of data. The main principles of these regulations are typically referred to as the ALCOA+ principles (Samson, 2021). The features necessary for the use of DCCs include some of the same functionalities that have already been required for current calibration management systems, e.g., user identification and access management.

As the systems must have the capability to manage and transfer DCCs and digital calibration requests (DCRs), the capability to generate and validate digital signatures or seals, which have been considered to be one of the main methods for securing DCCs, is also required. The signatures and seals can be used to authenticate the origin of the certificate and prevent any manipulation of its content. A noteworthy requisite for implementing the use of the signatures or seals is that there are different requirements or regulations in place for the formats of digital signatures or seals that must be fulfilled to ensure that they are legally binding. An example of such regulation is the electronic identification, authentication, and trust service (eIDAS). At a general level, the system also ought to be compliant with the common data security requirements defined, for example, by the ISO 27000 series of standards on information security.

3 Architecture for data exchange and DCC services

The Microsoft Azure cloud services were selected as the platform for the system architecture because they are being used in the LOGiCAL cloud-based calibration management system, also making them a sensible choice for the data exchange and DCC services. The different Azure services used in the concept design were as follows:

• Azure App Service as the platform for hosting the main applications;

• Azure AD for user identification access management;

• Azure Binary Large Object (Blob) storage for storing unstructured data, such as measurement results from calibrations;

• Azure SQL Database for storing and managing relational data, such as metadata on the data stored in the Blob storage;

• Azure Virtual Network for securing the Azure environment and limiting access to the SQL Database and Blob Storage; and

• Workspace-Based Application Insights for sending telemetry to a Log Analytics workspace.

In addition, the data exchange system was designed based on the following web applications:

• A REST API is used for the communication between the data exchange and DCC services and CMX or third-party systems. The communication through the REST API uses the hypertext transfer protocol secure (HTTPS) protocol so that the communication is secured with the transfer layer security (TLS) protocol.

• A Google Remote Procedure Call (gRPC) API is used for the communication between the data exchange service and data exchange client.

The overall system architecture includes the following services:

• data exchange service,

• data exchange client,

• DCC service,

• public REST API(s), and

• signature/seal service.

The services are used for communication between the existing systems (i.e., CMX and LOGiCAL); this communication is implemented in a similar style to the data exchange service and consists of the main LOGiCAL application and LOGiCAL Sync. An overview of the exemplary system architecture based on the Beamex calibration ecosystem is presented in Fig. 5.

Figure 5 Concept architecture showing the relations of the individual services of the Beamex calibration ecosystem.

The following subsections describe the individual services and two example workflows of calibration processes based on the presented concept.

3.1 Data exchange service

The data exchange service is the main application of the system that is used to manage the data exchange between the existing Beamex systems.

3.2 Data exchange client

The data exchange client is run on the calibration devices (i.e., calibrators and mobile devices running the bMobile calibration application) to establish the connection between the calibration devices and data exchange service.

3.3 DCC service

The DCC service is used to perform the majority of the functions related to the DCC and DCR. The DCC service is also used as the long-term storage for the DCC and DCR files. The functions of the DCC service include the following:

• generating a DCR from the information of the instrument that is to be calibrated, the required calibration procedure, and other information relevant for performing the calibration;

• converting the calibration procedure data included in a DCR into a format used in the calibration devices;

• generating a DCC from the calibration results and other associated information, such as the used reference instruments and calibration procedure;

• converting the calibration data in a DCC to formats used to manage calibration results in the calibration management systems;

• validating DCCs against the associated DCC schema versions and the DCR according to which the calibration is to be performed; and

• generating human-readable versions of DCCs.

3.4 Public REST API(s)

One or more public REST APIs enable the data exchange from the data exchange and DCC services to CMX and third-party systems. Communication uses HTTPS, which the commonly used web protocol, and is secured with the TLS protocol.

3.5 Signature/seal service

A signature/seal service is included in the system to secure the data transferred between the data exchange service and third-party systems (i.e., the DCCs and DCRs). In this application, digital seals will be primarily used because they correspond to an organization, whereas signatures correspond to individuals. However, the methodology is otherwise the same. The presented concept uses the eIDAS regulation as the legal framework for the seals. In order to be compliant with eIDAS regulation, the seals for XML-based documents (such as the DCC and DCR) need to use an XML advanced electronic signature (XAdES) format.

3.6 Workflow examples

This section describes step-by-step workflow examples of how the system would process and manage the data, starting from the calibration request and ending with receiving the DCC. Some steps of the actual workflow, for example, related to the user identification or assigning calibrations to technicians, are not included, as they are not directly related to the functions of the data exchange or DCC services.

3.6.1 A calibration is requested from a third-party calibration management system and performed by a service provider using a calibrator or calibration application on a mobile device

The first workflow example corresponds to a calibration process in which a calibration customer using a third-party calibration management system requests a calibration from a service provider that is using Beamex systems. This process progresses as follows:

1. a DCR is generated and signed or sealed by the customer,

2. the DCR is transferred from the calibration management system via the public API,

3. the DCC service sends the DCR to the signature/seal service,

4. the signature/seal service validates the signature or seal of the DCR,

5. the validated DCR is returned to the DCC service,

6. the DCC service converts the calibration procedure from the DCR into a format used in the calibrators and bMobile,

7. the calibration procedure is sent to the data exchange service,

8. the data exchange service sends the calibration procedure to data exchange client,

9. the calibration procedure is imported to a calibrator or mobile device with bMobile,

10. calibration is performed and documented with a calibrator or bMobile,

11. calibration results are sent from data exchange client to the data exchange service,

12. the data exchange service sends the results to the DCC service,

13. the DCC service converts the calibration results into a DCC,

14. the DCC service validates the DCC against the DCR and the requested DCC schema version,

15. the DCC is sent to the signature/seal service,

16. the signature/seal service generates a digital signature or seal for the validated DCC,

17. the signed/sealed DCC is returned to the DCC service,

18. the DCC service sends the DCC/calibration results to the customer's calibration management system via the public API,

19. the DCC is transferred via the public API, and

20. the DCC is validated and approved by the customer.

Figure 6 presents the workflow as a sequence diagram. If the calibration is performed internally by the company that owns the instrument and it is sufficient for them to have the results stored in their calibration management system in a format other than a DCC, the process can be streamlined, as the calibration request and results do not need to go through the steps involving the DCC and signature/seal services.

Figure 6 A sequence diagram of the first workflow example.

3.6.2 A calibration is requested from an on-premises calibration management system and performed by a calibration provider using a third-party calibration system

The second workflow example corresponds to a situation in which a calibration is requested by an organization that uses an on-premises system (CMX) as their calibration management system and the calibration is to be performed by a service provider using a third-party system capable of using DCC and DCR to exchanging the calibration-related data. This process progresses as follows:

1. a request for calibration is generated in CMX,

2. the request is sent from CMX to the DCC service via the public API,

3. the DCC service generates a DCR from the request,

4. the DCC service sends the DCR to the signature/seal service to be sealed,

5. the signature service seals the DCR,

6. the signature/seal service returns the DCR to the DCC service,

7. the DCC service sends the DCR to the calibration provider's system,

8. the DCC is transferred via the public API,

9. the calibration provider receives and validates the DCR,

10. the calibration provider performs the calibration,

11. a DCC is generated from the calibration results and signed/sealed,

12. the DCC is sent from the calibration provider's system to the customer,

13. the DCC is transferred via the public API,

14. the DCC service sends the DCC to the signature service,

15. the signature service validates the signature or seal of the DCC,

16. the validated DCC is returned to the DCC service,

17. the DCC service validates the DCC against to the DCR and the requested version of the DCC schema,

18. the DCC service converts the calibration results from the DCC into a format used by CMX,

19. the calibration results are sent to CMX,

20. the results are transferred via the public API, and

21. the calibration is approved by the customer.

Figure 7 presents the workflow as a sequence diagram. If the customer uses a cloud-based calibration management system instead of an on-premises system, the workflow is mainly the same; however, for the former, the API would not be needed for communication between the calibration management system and the DCC service.

Figure 7 A sequence diagram of the second workflow example.

4 Discussion

As the design requirements were partially conflicting in this work, due to the fact that compatibility with both on-premises and cloud-based calibration management systems was required, the concept has some compromises. The selected cloud-based approach is efficient and easy to set up and manage. However, if an organization does not wish to establish a connection between the calibration management system and cloud-based services might not be possible as presented without additional measures or changes in the architecture. An alternative approach could be running the services on a local server, although that may introduce some limitations with respect to the use or functionalities of the services as they have been described in this paper.

As the presented concept has not yet been fully implemented, a natural continuation in the development would be a proof-of-concept implementation for testing the system with its intended use cases. As there are several systems with which the data exchange service is intended to work, both within and outside of the Beamex ecosystem, the number of combinations of different test cases and respective workflows to be tested is high. Thus, thorough testing is required.

The DCC as a standard is still under development with respect to the consideration of the requirements for fully DCC-based calibration processes at the industrial level. The goal regarding defining the contents of the DCC is that they are described in an unambiguous way that ensures the correct interpretation of the data. This is also essential for the validation of the data included in the DCC. Semantical descriptions of the contents of the DCC are being developed to achieve the required level of unambiguity. Although the compatibility of different versions has been given a high priority in DCC development, differences between major releases can mean that direct backward compatibility cannot be achieved. At the same time, diversity in the field of metrology means that there is a high likelihood that various versions of DCCs are simultaneously being used in different industries, as the involved organizations might have different preferences regarding which version they use based on suitability with their existing systems. Ideally, the calibration service providers would have the flexibility to generate the DCC according to the specification that the customer requests. However, at this point, it is still difficult to estimate how feasible that will be because capability and flexibility may vary greatly between different organizations, depending on their available resources and systems.

A similar challenge can be found regarding the requirements for the digital signature/seal configurations that the system will eventually need to comply with, as these have not yet been widely addressed within the metrology community at a global level. The eIDAS regulation used as an example of a legal framework for digital signatures is mainly in use in the European single market; whether this framework will become a common framework in the metrology infrastructure or if it needs to be supplemented by other signature types in other regions remains to be seen.

5 Conclusion

Establishing a universal framework for the exchange of calibration data has been a high priority in the recent research and development efforts of the metrology community. The standardized format for the DCC is one of the cornerstones in establishing this framework. However, adopting the DCC for use in the industry requires that current systems are adapted to the new format. One fundamental change that the use of DCCs will introduce is that interfaces between the calibration service providers and their customers need to be established to achieve the full benefits of digitalization. If the DCC-based exchange of calibration data is considered, a fully cloud–based implementation would simplify things from many aspects. However, as there are very different requirements in different industries, developing a singular system to fulfill these requirements is simply not possible. The presented data exchange system architecture concept was designed to provide a common method for enabling the transfer of DCCs and DCRs for the existing Beamex calibration systems. This eases the process of adopting DCC use, as the number of interfaces needed for data exchange from and to third-party systems can be kept at a minimum. However, use cases in which a cloud-based solution is not viable, for example, due to strict data security requirements, will still require additional investigations.