IIC RA: Functional Viewpoint

As indicated in the corresponding section of Part II, the functional design focused on a lightweight analysis suitable for an agile development approach, as opposed to a fully-fledged, detailed specification. In particular, there was a strong focus on UI mock-up creation for the users of the system.

Getting Started: UI Mock-Ups

The initial UI mock-ups created during this phase are shown in the following figures. The team decided to focus on three main screens and put the more complex configurations into a specific menu (shown in the top-right corner of the UI mock-ups).

The first screen, shown in the following figure, depicts the assets within the different shop floors (for example, asset tracking). Usually, a factory is split into different halls or areas, which can be easily selected. The map shown at the right-hand side allows for scroll and zoom operations. Currently active nutrunners are shown in green, while disabled nutrunners are shown in red. The user should be able to click on a specific nutrunner location to obtain more information. If they click the link within this information, they are directed to the tool-specific screen within asset management.

The tool-specific screen shows the data transmitted by the assets. The user can select an asset and see the available data transmissions sorted by time, as in the following image. A detailed view is shown on the right-hand side. In the case of the Nexo nutrunner, this includes a visualization of the tightening run data (tightening curve), the program used, the status, as well as the time and location information.

The last UI mock-up screen discussed focused on the KPI dashboard. Interestingly, the team was initially unsure about the core KPIs. While the experts from Tech Mahindra discussed more than 60 different manufacturing-specific high-level KPIs, other partners wanted to cut these to fewer than 10 of the most important ones, since the testbed implementation should focus on the core ideas of the Track & Trace scenario and not become too industry specific. It was decided to move this discussion to a later date, which was made easy due to the agile implementation approach selected.

Domain Model

The team created a high-level domain model, as shown below. For the sake of clarity, we omitted most of the detailed attributes. The model follows a formal style that requires one root node (stereotype “root_instance”) under which all nodes are subsumed. Since the Track & Trace solution should be operated by different parties as instances of the testbed, an operator was defined. Each instance is made up of three core elements: assets, maps, and geofences.

The assets represent the tools managed; in the current phase, the focus is on power tools (shown by an inheritance). Each power tool has to provide a battery status and an operational status as well as a MAC and IP address, as discussed earlier. The domain model highlights the possibility to support different power tools, again depicted by inheritance. The nutrunner power tool has a sub-model attached, according to the definition from Rexroth (simplified view). Basically, each nutrunner has a set of tightening programs as well as tightenings (runs), each of which is associated with a specific program. A tightening program is made up of several tightening steps, which define different target angles, torques, etc. An individual tightening is composed of multiple tightening curves, each representing a concrete run of a tightening step.

Each asset has one or more assigned geofences. A geofence is a geographic polygon that describes the inclusive or exclusive area in which the tool is allowed to operate. To enable visualization, maps are used to provide visual representations of where geofences are located. One example would be a map of the different shop floors in a factory.

Asset Integration Architecture

The initial Asset Integration Architecture (AIA) for the Track & Trace testbed is depicted in the image below.

Basically, the Bosch Rexroth nutrunner already provides all the functionality required for the devices and the on-asset business logic level. Furthermore, its integrated FTP client and web server place it in the gateway domain in the AIA. The nutrunner communicates via wireless 802.11a/b/g with Cisco 3700 access points and with a router that centralizes the management of these access points.

The Wi-Fi router forwards wireless visibility metadata from all devices connected to the managed access points to a Cisco Prime Server with Mobility Service Engine (MSE). The physical location of the access points is configured in such a way that every Wi-Fi device is always visible within the scope of multiple range-overlapping access points. Based on the different signal strengths for a single device received by multiple access points, the MSE can triangulate the position of each particular device within the Wi-Fi coverage area using the metadata received.

The non-metadata communication of the nutrunners (for example, TCP/IP traffic) is routed to the Bosch M2M middleware, which manages the nutrunners from a logical point of view. The M2M backend hub provides an abstract information model that represents the capabilities of the nutrunners. The information model is connected to specific drivers representing different types of nutrunner. The Bosch M2M central repository manages the information models as well as all devices connected to agent hubs, and provides a REST-full interface to the Track & Trace operations.

Mapping the Domain Model to the AIA

The mapping of the Domain Model to the AIA is important, because it shows how the data will be distributed in the system. The figure below shows how this mapping has been carried out for Track & Trace. The following can be observed:

1. All asset-related data is centrally managed by the central asset registry component in the backend.
2. Asset details (such as tightening curve, etc.) are distributed between the backend and the assets themselves. The backend stores this data for all assets for a long time, while the assets only store their own data, and for a limited time only.
3. Geolocation data is managed by the Cisco component in the backend.

SOA

The definition of a set of open interfaces is one of the key deliverables of the Track & Trace testbed. The goal is to have a modular architecture, which allows integration with different industrial power tools, but also with different indoor localization technologies.

To achieve this goal, the interfaces will be grouped into three main areas:

• Asset-specific data and functions, such as asset location, geofence definitions, geofence violation events, etc., as introduced in the asset, map, and geofence entities in the Domain Model.
• Data and functions specific to hand-held power tools, such as tool status, battery load, battery life, emergency shut-down, etc., represented by the power tools entity of the Domain Model.
• And finally, tool domain-specific data and interfaces, such as for nutrunners, riveting tools, measurement tools, etc.

The following figure provides an overview of the layering of these three sets of interfaces.

As discussed in the interview with Roman Wambacher in Part II, managing large numbers of complex interfaces to highly heterogeneous assets and devices is one of the biggest challenges in an IoT project. In Track & Trace, we are looking at integrating different tools from different vendors, such as drilling, tightening, and riveting tools. Each tool interface can be quite complex, with hundreds of different properties and functions. In addition, the interfaces are likely to evolve over time, meaning that we will have to deal with multiple versions of interfaces. To address this challenge in the Track & Trace testbed, we decided to standardize on a common language for defining tool interfaces. This language is based on the Vorto Open Source standard, which is managed by the Eclipse Foundation as part of their IoT stack (more details here: https://projects.eclipse.org/proposals/vorto). Vorto is a standard that supports the definition of interfaces for complex hierarchies of assets and devices in the IoT. Technically, Vorto defines a DSL that can be used as an Interface Definition Language (IDL) for the IoT. Vorto comes with a set of valuable tools such as code generators to support different communication protocols like MQTT, as well as a repository to manage asset and device interfaces.

One key deliverable of the Track & Trace testbed is a repository of interfaces for different tools that can be integrated in the solution. This enables tool vendors to provide implementations of these interfaces for their individual tools. Or, alternatively, manufacturers can use this mechanism to integrate tools from different vendors themselves. Because of the importance of providing a set of open standards for Track & Trace, the project plans to work with the Object Management Group (OMG) on the standardization of tool interfaces, as well as with the Eclipse Foundation on managing the associated open-source aspects.