Result set #7 (Trust and Security): Confirmed as important. In this context, it was suggested that safety must be added here (or in a new result set). An example given here was worker safety during the tightening process.
Result set #8 (Reliability and Resilience): Confirmed as important; here, with a reference to OEE (overall equipment effectiveness), which again is industry-specific.
Result set #9 (Verification and Validation): Confirmed as important, with a reference to hardware versus software perspective.
Result set #10 (Service Operations): Confirmed as important, with a reference to the need to differentiate between the supplier service operations (support hotline and services, cloud operations) and the onsite support operations (tightening system support team at the factory).
Overall, the list was seen as comprehensive, with one reference to safety as a missing point that could be added either to #7 or as a new result set.
For the IgniteWorx rules, one suggestion was to look at the use of machine learning. A high level of complexity of the on-asset processes (in this case, the control of torque and angle) could indicate the need for machine learning-based evaluation of process data in the backend (e.g., the mapping of tightening curves against control curves).
flow rates
contamination
power
speed
Depending on the specific parameter, specialized IIoT sensors must be deployed, combined with data capturing and analytics. The next step is to use the data and analytics results for maintenance. Muhonen et al. (2015) describe condition-based maintenance (CBM) as a maintenance strategy “based on the actual condition of the asset”: “Unlike in planned scheduled maintenance, in which the maintenance is done based on predefined scheduled intervals, in CBM the maintenance is done when it is caused by asset conditions.”
5.5.2 Reactive Maintenance
Reactive maintenance is based on an approach where equipment is restored to normal operations after a breakdown. Condition monitoring can be used to inform the operator if a repair is imminently required. Also, the condition monitoring data can be used to help identifying what kind of repair is needed.
While this approach has many disadvantages (especially potentially longer equipment downtimes since the repair can only start after the failure), it still seems very common.
For example, Hemmerdinger (2014) reports that 55 percent of US building operators rely on reactive maintenance approaches for their equipment in buildings.
5.5.3 Proactive Maintenance
Proactive maintenance is using condition monitoring data to help anticipate and manage equipment failures before they actually occur. To detect deteriorating equipment conditions based on parameters such as those listed above (e.g., vibration, temperature, flow rates, etc.), usually advanced computational concepts such as machine learning must be deployed (Mobley, 2002). A number of different concepts can be identified supporting proactive maintenance:
Preventive maintenance: Regular maintenance intervals, determined by uptime statistics. According to Swanson (2001), “This type of maintenance relies on the estimated probability that the equipment will fail in the specified interval. The work undertaken may include equipment lubrication, parts replacement, cleaning and adjustment.”
Predictive maintenance: According to Swanson (2001), “Under predictive maintenance, diagnostic equipment is used to measure the physical condition of equipment such as temperature, vibration, noise, lubrication and corrosion. When one of these indicators reaches a specified level, work is undertaken to restore the
equipment to proper condition. This means that equipment is taken out of service only when direct evidence exists that deterioration has taken place.”
Prescriptive maintenance is based on predictive maintenance but proposes prescriptive maintenance measures in addition. Matyas et al. (2017) write, “Based on the analyses of historical data and incoming real time data, required maintenance measures are predicted by a system and a course of action is prescribed.”
5.5.4 Project C: Remote Maintenance System Architecture
The system described in project C of this case study is mainly supporting reactive maintenance, according to the definitions above. Figure 85 provides an overview of the system architecture. In this example, the applied domain is commercial buildings. In this domain, equipment deployed in the building is functionally highly diverse and technically heterogeneous, including intrusion detectors, fire detectors, video cameras, access management, shading controllers, lighting, heating, ventilation, and air conditioning.
Figure 85: Remote maintenance system for commercial buildings
The remote maintenance system examined here is a generic platform for remote maintenance of devices in the field. The focus is on retrofitting of existing human workflow-centric environments, as well as the enablement of secure, virtualized on-demand device connectivity and digital workplace provisioning. This is a standard product that can be customized for different customer requirements.
The system is utilizing gateways to connect locally to these different types of equipment.
The gateway is connected to a demilitarized zone (DMZ). In the DMZ, a virtualization platform is used for on-demand instantiation of remote-monitoring clients. These clients often run on legacy operating systems managed and instantiated by the virtualization platform. Service agents can then use the different remote monitoring clients for maintenance purposes.
5.5.5 Lessons Learned
One key lesson of this project was that heterogeneity is a clear driver of complexity.
Given the many different types of equipment that often must be integrated by this solution, this is a key cost driver. This project has the requirement to integrate many different legacy protocols, APIs, and legacy remote-monitoring clients in a secure manner.
Security is another driving force, especially the requirement to minimize the amount of time during which the backend stays connected to equipment in the field.
The virtualization architecture needs to play hand in hand with the connectivity architecture to support these requirements.
5.5.6 Findings for IgniteWorx
Regarding the Ignite project assessment, important feedback was regarding the project environment. This relates especially to the IT organization that builds and operates the solution. The recommendation was to define a new dimension as follows:
Dimension IT Organization
Description Please indicate the type of IT organization that will be responsible for building and operating the IIoT solution.
Options 1) Small team, single location 2) Small team, multiple locations
3) Multi-tier IT organization, with different responsibilities for network, database, server ops, etc., in single location
4) Multi-tier IT organization, with different responsibilities for network, database, server ops, etc., in different locations
Regarding the IgniteWorx result sets, the feedback included:
For project management methodology, also consider ad-hoc project management.
This is a management style very often found in projects with stakeholders from multiple organizations. Ad-hoc project management does not follow any of the established project management methodologies; it is, as the name implies, ad hoc.
For technology selection, one should not only focus on new technologies but also on integration of existing systems and legacy systems.
For risk management, the organizational risks also must be considered: who is defining the requirements, who is implementing the system, who is operating it?
Also, risks are different for standard products versus custom-built solutions.
Finally, regarding the IgniteWorx rules, the following was proposed:
A high number of assets in the field is a strong indicator that OTA updates will have to be supported. The interviewee suggested that there is a “Murphy’s IoT law”: “If it is not remotely accessible, it will break and require remote updates.”
A high number of stakeholders requires efficient stakeholder management.
A long project duration (or project solution lifetime)
o Increases the risk of changes to the customer organization, which makes tracing of requirements difficult.
o Requires efficient management of technology evolution. The example given was RDBMS versus NoSQL-DBMS for telematics data.
While the last three points sound like fairly generic observations, the interviewee was specifically referring to the requirements for the integration of many different asset categories in a heterogeneous environment. Thus, the suggestions must be seen in this light.