Navigation
  • The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling
    The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling
« Process, Rules & Events: Critical Business Modeling Methods | Main | Use Cases for the Internet of Things »
Wednesday
Oct052011

Part Two Use Cases for the Internet of Things: Definitions 

In the things world, there are patterns of events, decisions and process responses.  Simplistically, there are 3 classes of ‘things’:

  • Appliances, including machinery such as electric vehicle charging stations
  • Energy Sources and Sinks, such as solar photovoltaic 
  • Sensors

These things respond to commands and generally act as a participant on a local basis, such as in a DC Microgrid and on a more global basis as in the smart grid Reg.-on or Reg.-off and spin reserve commands. The objective of this modeling, if not the internet of things, is to achieve combinatorial interoperability. I will save the definition of this for the end.

(Business) Event:  In information technology, a business event is an event that is meaningful for conducting commercial, industrial, and governmental or trade activities. In the context of the use case, the events we want to detail are those that start, end or modify the thing in our use case. In other words, what happened to stimulate your use case? Sensors and groups of sensors could affect or signal local and global processes.

Business Event Factors:

  • Event Description: Events should be described by what takes place and where. For instance a cloud passing over a solar panel might be an event that affects solar technology. A brownout might signal the start of a smart grid scenario.
  • Detection: How can we tell that the event has occurred? What sensors, user request  and information provide this? Normally this is a decision or a group of business rules.
  • Control: Does the event stop, start or interrupt the process? What process is affected by the event?
  • Process Controlled: What product-related functionality or processes are controlled by this event?
    Related or Connected Process:  Our ‘things’ use case should start with an appliance’s functions or process, as it responds to events (or sensors). In IT a process is an event-controlled flow of coordinated activities that accomplishes a goal. What are the core processes that accomplish the use case for the ‘thing’? In technology, there may be many sub-processes needed to complete the core business process.

Process Factors:

  • Appliance, Business Model or Business Area: Processes support a product’s business model. A process accomplishes a goal in one or more business areas. What capability or features of the system are utilized in the use case?
  • Activities: What are activities that comprise the process? For things, appliances or energy sources, what components within the product will carry out the directives of the use case?  Only components or the types of components affected by use case analysis should be gathered. Since this is a high-level use case, there should be relatively few.
  • Participants: Who participated in the activities in part of the process (sub-process)? This can include products such as solar panels and boilers. It can also include sensors.

Business Process Technical Factors
Process Data: What are the data attributes within the message flow process? What documents and artifacts should be included?

  • Flow Control: What are the decision points of the process?
  • Related systems. What systems must provide data to the system?

Decisions and Business Rules:  A decision is a judgment about a business or operational concept. There are two major decisions in most use cases: How is the event recognized? Next, for the end-user or other stakeholder, how should the appliance, energy source or local process decide  to respond to the events?
Decisions can be controlled by users as in an automated sensor control. A business rules is a constraint or policy that guides the behavior of the business. Business rules mediate the information in the process flows.
Decision Factors:

  • Decision: What are the decisions that guide the use case? The decision is a lead-in for the formal statement of the rule.
  • Business Terms: What are the terms or vocabulary of the business rules? (In this study, business terms are left for Business Rules Approach problems)
  • Stakeholder: Who are the stewards for the business rules? Who controls the policy, constraint or guideline?
  • Control: What is the control motivation for this business rule? What is the consequence for the reversal?
  • Measure: How do we measure the outcome of the rule, both (if needed)?

Decision Technical Factors:

  • Formal Rule: the decision or rule statement in an If- Then-Else form.
  • Classify: the type, the division, the sort. A concise business rule will start (or end) by filtering what it is deciding upon.
  • Calculate: compute formulas, look up data and statistics, and transform and assign values. The rule transforms input values into useful data.
  • Compare: the comparison to the redline. The redline is a key value that must be reached, or not exceeded, or within a specified range.
  • Control: what is true or valid, correct or mistaken, and the data and messages that go with them. Control can include a transformation of data.

Combinatorial Interoperability

Interoperability is the capability of diverse systems and organizations to work together (inter-operate). The term is often used in a technical systems engineering sense, or alternatively in a broad sense, taking into account social, political, and organizational factors that impact system to system performance.

In the ‘things’ world, interoperable appliances, systems and energy sources can recognize each other and cooperate to meet the needs of the owner. For instance a temperature sensor on one device might control another. The network should sense when the sensor is available and the other devices should interoperate with these.

Certainly, the Event, Process, Decision metaphors apply to developing use cases for the internet of things. 

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (1)

Great Article Tom. Would love to hear more from you on "Business Rules".

October 8, 2011 | Unregistered CommenterAbhishek MIshra

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>