This chapter provides the overview of a ‘OPC UA Information Model for Tightening Systems’. This Information Model provides the necessary ObjectTypes to model a tightening system.
Figure 7 - Overview of the Tightening System Information Model
This document describes modelling of various tightening systems like fixtured system, handheld system, intelligent tool etc.
In this version of the specification, tightening system consists of models for assets, results, basic events.
Assets provide a way for an external system to understand the physical representation of the system and is a vital “skeleton” for many other core models and functions, such as for example condition monitoring.
Result reporting is the most important and common use case for communication with a tightening system.
Assets are various components of a tightening system. This version of the specification describes the physical assets which are parts of the system that can contain a processor or electronically interact with a part containing a processor.
The assets are modelled using the generic object declaration BaseObjectType place holders to ensure interoperability from various other domain specifications.
This specification defines set of interfaces for each type of asset and asset instances can be implemented by including the required interfaces defined in this specification. The asset instances can also be modelled by external interfaces from other companion specifications or vendor specific extensions with the help of open generic model.
A controller can represent an entity that can control an aspect of the joining process. A controller can also be any kind of supervisory instance, which manages multiple tools. So, controller can be any kind of computation device which controls specific parts of the tightening system and communicates to another system. A tightening system may consist of multiple controller instances. The first controller in the list is intended to harbour the OPC UA communication for the Tightening System information model.
A tool (or spindle) represents a physical device that tightens a bolt. It can for example be held by a human being, attached to a robot, or be part of a multi-tool fixture.
A tool has usually a drive to perform the tightening operation. There may also be some kind of sensors involved to get the process status.
Note: Spindle is a common term used in Fixtured system to represent a specific type of Tool.
A servo amplifier represents a physical device that controls the motor in the tool. It is the physical power stage to deliver the power to the motor to perform the tightening or some other movement in the system.
Those memory devices may be implemented for example like memory cards or memory modules. Those are used to store data also during the power off phase of the device.
A MemoryDevice (or Storage Device) stores data, such as, the system identity, the software of the system, licenses, tightening programs, etc.
Each sensor is responsible for one measurement signal. Therefore, it measures one quantity and delivers the value by doing so.
The sensor data may be used in the system to perform the tightening, but also can deliver other information of the system.
Besides the measured quantity the sensor may expose its calibration information, which may be useful for quality assessment.
Cables are there to interconnect certain parts of the system. Example: Cable from a tool to a controller.
Note: For this version of the specification, Cables are only modelled in the system if the required information can be provided by the system.
Note: For this version of the specification, Batteries are only modelled in the system if the required information can be provided by the system.
A feeder stocks the fasteners and separates the elements and makes them available at the joint position. A feeder may also content a controller for managing the operation sequence.
Examples: Bunker, bowl feeder, step feeder, etc.
Accessories represents devices put on the tool or in the station to help the user understand and influence the tightening process.
Examples: Stack lights, socket selectors, screens, scanners, location tags, reaction bars, operator panel, etc.
Note: There are other specific companion specification for some accessories like Stack light, etc. and that model could be implemented in the current Accessory instance since all the assets are modelled as BaseObjectType placeholders.
A subcomponent is a system-specific part that can be plug-in or permanently installed and enables the tightening system to perform a specific task.
Examples: Radio modules, fieldbus modules, software modules etc.
The data related to condition monitoring is provided as part of the asset information model.
Example: Service Information, Error Information, etc. defined in 7.1.2.2, Battery Health Information defined in 7.1.2.9, Calibration Information defined in 7.1.2.7, etc.
This version of the specification defines minimal set of events which may be extended later. Refer the following section 8 for details.
Result is the core data from a joining system. It is set of measurement values which are generated when a joining operation is executed.
The result data is defined in a layered model to ensure interoperability between other joining techniques and companion specifications.
Tightening Result includes optional elements such as step results, traces, errors, and any other additional information to reference related objects like programs, joints etc.
Note:
- The systems which does not support multiple step program, it can be modelled as a single step in the result.
- This version of the specification does not define multiple-spindle result, batch result, job result, application result, etc.
