Model-Based Interfacing of Large-Scale Metrology Instruments

Large-Scale Metrology, in addition to its traditional applications, has become a backbone of novel manufacturing paradigms [1, 2, 3]. At the same time, the resulting cyberphysical production sytems are of growing complexity, accommodating increasing numbers of heterogeneous sensors and demanding interoperability [4]. Reference architectures as presented in section 1 formalize the data flow of such systems accounting for a large number of heterogeneous entities. An efficient implementation of such manufacturing systems requires apropriate communication interfaces to the Large-Scale Metrology Instruments. Throughout this paper, a protocol- and device-agnostic approach is described by apropiately modeling IoT protocols and instruments.

From the perspective of information technology, a measurement can be interpreted as self-contained microservice with defined capability and opaque system details, which is required to interoperate with other services [5]. Evertz et al. deduce three main concerns for their operability: The representation of data over a communication wire, the order and type of individual items in a message, and the physical meaning and scale of these items [6]. Regarding the latter question, an interface model based on a physical view of a Large-Scale Metrology instrument is developed in section 4. The first two issues are addressed by IoT protocols, e.g. OPC UA and MQTT. Common protocols are reviewed in section 3 to decouple the defined interface model from a specific protocol by establishing an abstraction layer. This allows the realisation of the microservice interface using mature and widely supported standards and thereby to reduce implementation effort and development environment confinements.

The entire approach is validated for a laser tracker in section 5 used in a cloud-based machine tool calibration application.

Within the concept of the Internet of Production, a semantic four-layer architecture for cyberphysical production systems shown in figure 1 is proposed [4]. The first layer represents the raw data sources, including sensor data, product and process information. It is followed by a provisioning layer, which is required to enable access to different data sources with heterogeneous communication patterns and protocols. Within the third level, the aggregated data is processed, e.g. using model-based data reduction or learning algorithms to serve as foundation of data-driven decisions associated with the top layer. The latter is constituted by applications supporting a human user taking a decision and algorithms for automated system control, effectively leading to closed-loop behaviour as the raw data on the lowest level provides feedback signals. The data flow occuring in industrial Large-Scale Metrology can be associated to the aforementioned model: Measurement instruments, nominal models and process descriptions represent the raw data. Geometric analysis and further processing of the measured coordinates reside in the third layer. A digital Geometric Design & Tolerancing report is an example for user-oriented decision support, while metrology-assisted autonomous vehicle and robot guidance are exemplary autonomous systems within the top layer [7].

The model-based interface proposed by the authors addresses the data provisioning layer. With the high variety of existing Large-Scale Metrology instruments and their proprietary interfaces, the integration of a new device into an existing system poses a significant effort [1, 8]. Even if the communication over the network is harmonized using common IoT protocols, the interface model,i.e. structure, identifiers and definition of functions and variables can differ and thereby require a manual adaption of existing applications in the processing layer when the instrument providing the data changes. This impacts the selection of a device via its indirect cost, conflicting with the ambition to choose a measurement instrument solely based on the metrologic capabilities required by the application [9]. By structuring the device interface using a generalized functional model prior within the utilized IoT protocols as proposed in section 4, this limitation can be overcome.

IoT protocols enable multilateral interfacing among the devices and applications within the defined layers by defining how data is exchanged on an information technical level. Within most of the protocols, common characteristics can be identified from a practical perspective. In their following descriptions, the term message refers the entirety of data transmitted including protocol-related overhead.

Table 2 assesses these properties for selected IoT protocols. Figure 2 outlines the message processing to a set of explicit actions required by the microservice resource implementation. They are utilized to establish an abstraction layer decoupling latter implementation from the use of a specific protocol. A mandatory prerequisite therefore is a model of the functions and data as resources of the microservice represented in serializable fields organized using unique (preferably structured) identifiers. Table 2 explains this set of actions the resource implementation must react to. At the same time, the actions are matched with different protocol-specific methods. To reduce complexity, the authors propose a division of resources into objects, functions and variables reacting to specific subsets: Objects provide an object-oriented resource model and are the only resources allowed to possess dynamic child resources. Functions are resources that are callable with a set of argument and return values. Variables encode read and potential write access to primitive data fields. Authentication is regarded as protocol-specific task, while authorization is interpreted as resource-specific question if an action is allowed for a given combination of user and resource identifier and therefor not discussed in further detail.

Utilizing the abstraction layer, a device whose resources can be modeled in objects, functions and variables for which its internal software implements the respective subset of actions can be linked to any arbitrary protocol. The only requirements imposed are the expression of methods as aforementioned actions and handling of resource identification, authentication and serialization. Moreover, simultaneous interaction over multiple protocols is enabled as well as the deployment of adapters between protocols [10, 6].

The interface implementation of a Large-Scale Metrology instrument can be decoupled from a specific protocol if its functionality is modeled in objects, functions and variables as stated in section 3. Therefor two modeling perspectives exist: A physical view tightly linked to the device representing its physical layout and a functional view oriented along the information and functions (i.e. resources) expected from the device. For the simple example of a traditional 6DOF robot these perspectives translate to either modeling its position command interface as six individually controllable joints or as kinematic capable of moving its tool center point in three directions and rotate around three axes. While the first view may result in a more accurate description , the latter perspective offers the advantage of uniformly modeling different devices providing the same capabilities in a black-box manner and thereby enabling their interchangeable use, e.g. realizing a kinematic with six degrees of freedom by either a robot or a machine tool.

Thinking of instruments as microservices, a functional view around the position information¹¹1Position information is regarded as the measured position, orientation (if supported), associated covariance and, if applicable, traceability details. of the system’s mobile entities presents an essential part of a possible model-based interface. At the same time, Franceschini et al. classify LSM instruments according to their hardware organization into distributed and centralized systems [8]. This offers a device-agnostic physical perspective for the interface if centralized systems are seen as systems with exactly one measuring station. Both approaches are combined in the interface model proposed in figure 3 using an object-oriented approach with base stations and target entities as main classes. The former are instantiated by the measuring stations of the systems, e.g. indoor GPS transmitter, ultrawideband anchors or a laser tracker head.

Instances of the latter are the mobile units whose position is actually determined by the instrument, e.g. physical computing entities (PCEs) of an indoor GPS or spherical mounted retroreflectors (SMRs). These provide the generic, consistently identified interface to their current position information, regardless whether they are passive or active units²²2For example, the position of a SMR is measured by the angular encoders and the distance measurement system in the head of the laser tracker but is interfaced via the SMR’s object instance..

An object is interpreted as class instantiation if it contains all functions, variables and child objects defined in the class. This allows to add device-specific (i.e. inferred from a physical view) resources to the individual model-based interface while maintaining the generic functional perspective, e.g. adding digital in- and outputs of indoor GPS PCEs as variables and effectively subclassing the entity class. Especially regrading the loosely defined Large Scale Metrology Object and Generic Device Object (cf. figure 3), adding additional device resources allows for seamless embedding of the proposed interface into more complex device models.

Probes are explicitly not covered by the proposed model as they are interpreted as devices themselves which rely on one or more target entities at defined physical interfaces. Moreover, a single instrument may be used with different types of probes potentially even unknown to the manufacturer. Following the microservice paradigm, a probing coordinate measurement system could be realised by a superordinate software accessing the position information of the Large-Scale Metrology instrument over its interface after a trigger signal has been received from the probe’s device interface.

The yet not further defined calibration objects account for traceable measurements on a physical and cybersecure level. It is intended to digitally represent a calibration certificate including a cryptographinc certificate in primitive fields, which is currently subject to research [11].

The model-based interface approach described in the previous section was evaluated for an API Radian^TM laser tracker. Its head is interpreted as the only base station defining the local coordinate system. The mobile entities consist of SMRs and other compatible targets, e.g. smart targets also measuring orientation. Multiple targets are used for convenience to facilitate automated network measurements and maintain the analogy to multi-target systems.

Figure 4 shows an flowchart for using a Large-Scale Metrology instrument’s continuous data stream taken from the application of calibrating a machine tool which was applied using a laser tracker interfacing the abstraction layer in a cloud-based Node-RED instance via HTTP/REST and MQTT [12, 13]. In a second use-case, an OPC UA based interface was used to integrate the same laser tracker into a robotic research platform to measure the deformation of a CFRP airplane panel [14]. Both use-cases showed that the device model introduced significantly reduced integration times. For future applications, two laser trackes have been added as a permanently available services to the network infrastructure of the authors’ laboratory shop floor.

The proposed interface model for Large-Scale Metrology systems allows to decouple the implementation and structure of the instrument’s resources from the use of a specific communication protocol. Subseqently, applications can be designed independent of the used measurement device. In combination, this facilitates their integration into complex, heterogeneous industrial systems. Leveraging the relatively small set of requirements to the instrument’s minimal implementation of the defined classes, the authors will apply the interface model to a Nikon iGPS^TM and Pozyx^TM ultrawideband systeme, such that these are available as sensor microservice to cyberphysical applications.