Findings on Ignite Dimensions

Three main lessons can be taken from the case study regarding the Ignite dimensions.

First, the overall findings are discussed. Second, the lessons learned regarding the concept of an asset in Ignite in general. Third, the different project perspectives and how to better handle them.

5.7.1.1 Overall Findings

Each of the projects from the case study looked at the Ignite dimensions with a different perspective. A number of interesting suggestions were made for extending the current Ignite dimensions. A visual overview is provided in Figure 88.

Figure 88: Overall findings on ignite dimensions

Maybe the most fundamental insight is that the current Ignite dimensions are lacking a dedicated dimension to cover the business perspective, including the supported use cases and functional requirements. Based on the learnings from the case study, this new dimension, Business Dimension/Functional Requirements, would require the following:

 Industry Domain: This would most likely be an enumeration or a selection list, meaning that one would have to break with the “four options per dimension”

principle. This would have a significant impact on any IgniteWorx implementation since this would require an extension to the data model and UI implementation. Also, the proposal for IgniteWorx rules that create mappings from Ignite dimensions to results in result sets would have to be reconsidered.

 Use Cases: Very similar to industry domain, at least in the ideal case, in which this could be mapped to a predefined selection list of use cases. However, it is unclear if a complete list of use cases that would fit all possible user projects could be compiled. Thus, this might even have to allow the provision of additional use cases as text input, which would make processing (e.g., via rules) much harder.

 Functional Requirements: This would require an open list, i.e., a user would be able to specify 1-n functional requirements as string values. This would be valuable input but also much more difficult to process for IgniteWorx rules compared to the four options approach or selection lists with predefined options.

While technically not easy to handle with the initial design of IgniteWorx, this should be considered for the next major release.

5.7.1.2 Asset as a Key Entity

Another key lesson learned from the interviews was that sometimes it is not immediately obvious what the asset is that the Ignite dimensions are referring to. One core idea for Ignite is that it should focus on assets instead of lower-level entities such as sensors and devices. The reason is that assets are typically what the business is focusing on; the asset is what you would find in the balance sheet of a company. The concept of an asset in Ignite allows one to look at dimensions like number of assets in the field, economic value add of assets, etc.

Figure 89: Different possible scopes of an asset in Ignite

However, during the interviews, it became clear that there often seems to be a fair share of ambiguity here. As is shown in Figure 89, an example is project C, which provides maintenance to domains like building facility management and security. In this example, it is not immediately clear what the asset is: the building, the legacy security appliance in the building, or the gateway that is deployed as part of the solution.

To overcome this ambiguity in Ignite, ISO 55000:2014 could be used (ISO, 2014). This standard provides principles and a clearly defined terminology for asset management.

5.7.1.3 Project Perspective: IIoT Solution Supplier versus Customer

Finally, another issue with Ignite that became visible through the cross-case analysis was a question regarding the project perspective. For commercial IIoT solutions that are typically sold multiple times, the question is which part of the project IgniteWorx is addressing: the perspective of the team that is building the solution or that of the customer implementing the solution in his or her company. This dilemma is exemplified in Figure 90.

Figure 90: Project structure for IIoT COTS solutions

It seems there are at least three options for the perspective that the user of Ignite could take on during an IIoT project assessment:

1. Development of IIoT COTS Solution (Solution Provider): In this perspective, it would be difficult to answer any question specifically regarding topics like assets (e.g., number of assets in the field) since the solution provider is not him- or herself deploying assets in the field. This gets further complicated in case the solution is provided by different suppliers for the IIoT backend solution and the IIoT hardware/embedded software, for example, the suppliers of the tightening quality assurance solution in project B, including the actual tightening system as well as the QAS solution

2. Rollout of IIoT COTS Solution (Customer): In this perspective, some details regarding the software development side in Ignite may be seen as irrelevant since in COTS projects no new software is usually developed

3. Development of Custom IIoT Solution (Bespoke Solution Development): This perspective would actually combine perspectives 1 and 2, so this would benefit most from the current structure of Ignite

Especially for solution providers (1), it seems to make sense to combine the provider perspective with a realistic example scenario for 2. For example, the provider could assume a typical customer deployment and use this to go through the Ignite dimensions.

This is what was actually done for the assessment of projects B and C in this case.