Proposed System Architecture for IgniteWorx

multiple potential results (e.g., from IgniteWorx result sets) to different criteria (e.g., Ignite dimension selected by an individual IIoT project). However, the different criticisms of AHP (e.g., Pérez et al. (2006)) will have to be carefully taken into consideration.

Artificial Intelligence AI in general as a concept is too broad to be evaluated here. As discussed in section 3.3.3.2, for phase 1 of IgniteWorx, formal logic might be the most suitable since it can be used to capture mapping rules explicitly.

Self-learning techniques will only be applicable in phase 3 of the IgniteWorx evolution once reliable reference data will be available.

Bayesian Networks Bayesian networks seem to be the most robust and proven approach for managing the causal dependencies and probabilities in IgniteWorx. They also support explicit knowledge modeling, which is key for phases 1 and 2 of the evolution of IgniteWorx.

Decision Tree Analysis Decision trees provide a simpler way than, for example, BNs to deal with causal dependencies and probabilities.

If the mappings between key IgniteWorx artifacts can be mapped to tree-like structures, they would be an option.

Multi-Criteria Decision Analysis

Again, MCDA is too broad a concept to be directly applicable to IgniteWorx. Instead, AHP as a key MCDA methodology is evaluated and considered here.

Table 24: Evaluation of related concepts for IgniteWorx

In conclusion, Bayesian networks and decision trees should be considered for the foundation of an IgniteWorx implementation, potentially in a hybrid implementation.

Analytics hierarchy process could also be of interest but must be treated with care given that it is not without criticism.

3.3.4.1 Expected System Architecture Evolution

As discussed in 2.7, it is assumed that any concrete IgniteWorx implementation will evolve in phases. These phases relate specifically to the availability of IIoT project reference data, as well as user feedback. In phase 1, the assumption is to have very little of both, in phase 2 the first meta data will be partially available, and only in phase 3 will the system have reliable meta data.

As a consequence for the resulting system architecture, this means, that at least for phase 1 and probably also phase 2, an IgniteWorx system will have to rely on explicit knowledge modeling, while only toward phase 3 will any meaningful, self-learning principles make sense.

Figure 61: Expected system architecture evolution

Figure 61 adds the suitable system categories to the system evolution diagram from section 2.7, showing where explicit modeling fits in and where self-learning recommender system technologies would start becoming relevant.

3.3.4.2 Initial Hybrid Architecture

Taking the above discussion on the expected system evolution into consideration, as well as the learnings from the research on suitable systems and concepts, the proposal is to use a hybrid architecture for IgniteWorx, which draws on the different concepts evaluated in sections 3.3.1 and 3.3.3.

Figure 62: Proposed IgniteWorx architecture

The proposed IgniteWorx architecture depicted in Figure 62 includes key concepts recommended in section 3.3.1, including the use of architecture components from expert systems, semantic reasoning systems, and survey engines.

The concrete architecture proposal includes three main components:

 IgniteWorx System Content Manager: This component supports storage and management of Ignite project dimensions, IgniteWorx rules, and IgniteWorx rule sets. Effectively, this components is a specialized content management system with a custom scheme and UI to support the aforementioned entities.

 IgniteWorx User Content Manager: This component supports project assessments and recommendation of IIoT project setups.

o Project Assessments: This module works like a survey engine, as described in section 3.3.2.5, driven by content from the IgniteWorx system content manager. Depending on user preferences, this module might support storage of project assessments either in the local browser (accessible only for the individual user) or in the backend (potentially shared).

o Engine: The IgniteWorx engine takes IIoT project assessments and creates recommendations for a concrete project setup. The engine must apply the IgniteWorx rules to the concrete project assessment data to create matching recommendations.

o Recommendations: The recommendations are the output of the IgniteWorx engine. The engine can make one recommendation per result set or provide multiple results per result set, including a ranking.

Recommendations should not only provide a link to the result details but also an explanation why a particular recommendation was made (this was described as a key feature of recommender systems, e.g., in the Hulu example). Also, expert systems typically include an explanation system (see Figure 54).

 IIoT Knowledge Base: The IIoT knowledge base must provide detailed explanation of the different results from the IgniteWorx result sets. This can either be a central knowledge base or a distributed knowledge base (e.g., the Internet) Each of these components could be implemented as a micro-service. This would ensure improved maintenance and easier extensibility of the system (Namiot and Sneps-Sneppe, 2014).

3.3.4.3 User Roles and User Interfaces

A clear understanding of user roles and user interfaces (UIs) is essential for any system design. In this section, both are described before being mapped against the proposed IgniteWorx system architecture outlined in the previous section.

Figure 63: User roles and user interfaces in IgniteWorx

Figure 63 provides an overview of the key user roles and required user interfaces in IgniteWorx:

 Ignite Project Dimensions Author (1): Responsible for creation and maintenance of Ignite project dimensions, using specialized UIs for this task

 Ignite Rules / Results Author (2): Responsible for creation and maintenance of IgniteWorx results sets, results and the rules that create the mapping between project dimensions and results, using specialized UIs for this task

 IIoT Subject Matter Expert / Author (3): Responsible for creation and maintenance of the content in the IIoT knowledge base, using specialized UIs for this task

 IIoT Project Manager: The end-user of the system, using it for assessing his or her individual IIoT project and getting concrete recommendations. Will require specialized UIs to support

o Project Assessment (4): The UI used to perform the project assessment based on the Ignite dimensions

o Project Assessment Outcome (5): The UI providing assessment summary and recommendations for individual project setup

The system implementation must ensure that the UIs as described above are provided in a way that allows efficient data capturing and presentation and also supports data privacy policies for the IIoT project manager to provide him or her with a choice of whether he or she is willing to share his or her project assessment data or not.