Asset Management is a container to group a set of assets and the respective methods.

Assets is a container which provides all the assets in a joining system described in the following sections.

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.

Note: For Accessories and SubComponents, there can be other companion specifications (Example: Stack light) and these models could be implemented at instance level since the assets are modelled as BaseObjectType placeholders.

This version of the specification is limited to assets which can expose data.

Figure 8 – Assets Overview

This is a container for the set of controllers in the system.

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 joining system and communicates to another system. A joining system may consist of multiple controller instances. The first controller in the list is intended to harbor the OPC UA communication for the Joining System information model.

This is a container for the set of tools in the system.

A tool represents a physical device that joins parts together. It can for example be a tool held by a human being, spindle attached to a robot, or be part of a tool fixture.

Note: Spindle is a common term used in a fixtured system to represent a specific type of Tool.

This is a container for the set of servos in the system.

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 joining or some other movement in the system.

This is a container for the set of memory devices in the system.

A MemoryDevice (or Storage Device) stores data, such as, the system identity, the software of the system, licenses, joining programs, etc.

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.

This is a container for the set of sensors in the system.

A sensor is a physical device whose measurements can be transformed and processed within a given system.

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 joining, 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.

This is a container for the set of cables in the system.

Cables interconnect certain parts of the system. Example: Cable from a tool to a controller.

Note: Cables are only modelled in the system if the required information can be provided by the system.

This is a container for the set of batteries in the system.

Battery is physical device which stores and provides energy to the required system.

Note: Batteries are only modelled in the system if the required information can be provided by the system.

This is a container for the set of power supplies in the system.

A power supply is a physical device which typically transforms or delivers power.

This is a container for the set of feeders in the system.

A feeder supplies the material for the joining process. It may stock fasteners and separates the elements and makes them available at the joint position.

Examples: Bunker, bowl feeder, step feeder, etc.

This is a container for the set of accessories in the system.

Accessory represents a physical device mounted on the tool or in the station to help understand or influence the workflow.

Examples: Stack lights, socket selectors, screens, scanners, location tags, reaction bars, operator panel, etc.

This is a container for the list of subcomponents in the system.

A subcomponent is a system-specific part that can be plug-in or permanently installed and enables the joining system to perform a specific task.

Note: These are the type of assets which cannot be modelled by the other assets defined in this specification.

Examples: Radio modules, fieldbus modules, etc.

This is a container for the list of software in the system.

A software is a system-specific software asset that can that be part of any physical asset.

This is a container for the list of virtual stations in the system.

A virtual station is a system-specific abstraction which can be used to group and manage processes and physical assets.