Challenge to determine the use case of IoT
The internet of things is characterized by the technical connection of devices and systems to the Internet. Although this connection is the starting point of many IoT projects, in most cases it can be implemented with relatively little effort after careful consideration of the available options.
However, the mere technical use of IoT does not create any value per se for the product, the process or the company as the product or process owner.
One of the challenges that must be considered at the beginning of a project is the definition of the so-called use case. The use case describes, among other things, the possibilities of interacting as a user or external system with the system under consideration.
These interactions should converge to a corresponding corporate goal, because the IoT application in the product or in the process then receives value through the later application. This application is built on the basis of the technical foundation, such as the data or the new communication options. We will cover the basic categories in which IoT applications can achieve value and how this can be quantified in a future post.
In practice, the use case definition for IoT is often faced with the challenge of switching between the technology perspective and the application perspective and systematizing the ideas of what could be achieved with a sensor, a sensor combination or an evaluation of the data collected. This article contains a methodical proposal as to how the back and forth from technology to application and from application to technology in the idea phase can be used in a systematic way when defining the use case.
What is "if this then that"?
Already in 2010 the service provider left in the USA IFTTT to the market. IFTTT means "if this then that" and describes a simple set of rules with so-called recipes that react with certain actions ("then that") based on an input event ("if this"). The application was highly praised in the media, which is most likely due to the simplicity of the structure of the rule sets. Simple automation tasks can be solved quickly with it, whereby above all the connection of various systems from different manufacturers is possible via triggers and actions.
For example, the detection of a person by provider A's cameras can switch on the light in the house via provider B. From a technical point of view, SWMS already has IFTTT in one previous post illuminated. But how does the approach behind IFTTT help with the use case definition for IoT systems?
The thought pattern "IFTTT" for use case finding
The simple structure of the thought pattern behind IFTTT helps with the use case finding, which takes place in practice in the field of tension between technological possibilities and actions or values to be achieved. It is important that we should only follow the simple thought pattern here and first free ourselves from the actual technology. It's just a matter of fundamentally determining that certain technical requirements alone or in combination lead to actions that then determine the value of IoT for the product or the process.
Often the easiest way to start is to record the status quo in terms of recorded data and sensors used, because in most cases IoT projects are characterized by the fact that an existing system or process is "digitized" and further automated shall be. Therefore, start by clarifying the current structure of your system under consideration. It is relatively independent of whether it is a product or a process that you are looking at. For example, a product already uses various sensors for internal control and uses them to switch actuators, such as in the swimming pool shown. Start and end times, quality criteria or certain machine settings may already be recorded in a process, albeit manually and possibly only sporadically.
From technology to application
Based on the simple idea of recipes à la IFTTT, ideas for new applications of the physical measurements and the collected data can now be derived and formulated from this collection. It is important that possible technical hurdles are consistently ignored. It is not a question of determining the specification in detail, but of formulating an idea in principle and systematically, which describes on the "if this" side which technically recorded situation results in which statement and possible action on the "then that" side should. A simple example using the example of a swimming pool: "If the outside temperature > 26 °C, then turn off the heating". Of course, the potential of IoT is far from being exhausted here, but you can model your use case according to the same scheme without more complex rules. Example: "If the chlorine concentration is low and the number of visitors is high and the last chlorine order is x days ago, then automatically order new chlorine". Here the value of the automation of the business process and the service becomes much clearer, because the technical parameters are used in combination to generate this value: namely a simplified and automatic ordering system, which significantly simplifies a task for the operator and at the same time an after-sales business for a pool builder allows.
From the application idea to the technology
Now the application idea in companies can also take on the initial role. Let's stay with the example of the pool. A pool builder can of course first ask himself how he will retain his customers after the sale and construction of the pool, for example, and may also come up with the idea that, among other things, the continuous supply of chlorine to his customers would be an interesting business. He is also convinced that he can get his customers to order chlorine from him on an ongoing basis if he succeeds in automating the regulation, control and inventory management that is annoying for the customer. "We have all the necessary data for that, don't we?" is the central question, which can also be used methodically with the help of "if this then that" modeling in such a way that the event trigger ("if this") is linked to the necessary technical conditions from the action (supply with chlorine, "then that") can be defined. It is often the stakeholders, ie customers, internal service employees, product development, etc., who provide the ideas or are the addressees of these campaigns.
The true strength - third-party systems and more
In our opinion, the success of the provider IFTTT lies primarily in the fact that manufacturer-independent connections were guaranteed. This means that almost endless combinations of sets of rules can be created without major technical restrictions due to the range of functions of individual manufacturers. Even when modeling the IoT system via this borrowed methodology, one should be aware that early technical limitations are to be avoided. In both cases, relationships can also be formulated vaguely, ie for example "if anomalies in the vibration sensor on the pump increase over time, then send a message to the connected ERP system".
Everything else that is conceivable in terms of data sources or events is suitable for defining the use cases. External data sources and systems in particular offer incredible potential for innovative approaches. Sources are for example
- Third party systems, e.g. tweets about the company, social media data
- Inventory systems, eg messages via the ERP system, events from the SCADA system, PLC data
- External data, eg weather reports, ambient values from the building technology
- Open data, e.g. traffic data, market data, statistics, ...
- Etc.
Conclusion
The term "method" is almost too broad, but in this article we have presented a simple procedure with which the application and action ("then that") are systematically derived from the technical possibility ("if this") and, above all, documented can be.
The second path from the application idea (“then that”) to the necessary technological requirements (“if this”) is also possible. Embedded in the description of the status quo, consisting of
a) the product or process that is to be “digitalized”,
b) the technical skills or data that it has so far and
c) the stakeholders who are interested in the actions,
this procedure leads to a simple description of possible use cases and thus to the possibility of deriving the use cases that are further considered within the framework of an IoT project.
