This document describes the architecture model and the basic functionalities of the Automation ESH Module.

Module Design

OSGi Runtime

The OSGi Runtime allows the Automation ESH module to be used.

Automation ESH

The main functionality of the Automation ESH module is provided by Automation ESH Core bundle. Of course the Automation ESH Core bundle will not provide alone the all functionality. It is designed to collaborate with other modules that are part of the solution. The Automation ESH module provides a set of module handler factories – "Factory Group" – that contains three system handler factories, as well as the ability for the users to define their own and add them to the system. The extendability is one of the important features of the module. The other important part of it are the resource providers - "Providers Group". The Automation ESH module provides two types of resource providers: bundle resource and system file resource trackers for the Rule, Module Type and Template resources. Also provides the ability for the users to define their own and add them to the system. The providers are tracked by the Registries and their resources are added automatically. The system module handlers need to cooperate with some other modules of the Bosch IoT SDK - Functional item Management module, Scripting module, REST module and Web Console, also use some of the features provided by the Framework system bundles – Timer service and ThreadPoolManager service.

Rules and Rule Engine

The Automation ESH module enables the user to define a set of rules that eliminate the need of human intervention when monitoring, managing and controlling of the various devices is needed, and provides an environment -the Rule Engine - that is responsible for automatizing the evaluation and execution of these rules.

Modules and Module Handlers

The Automation ESH module provides to the user an easy way to build these rules from small pieces - modules, which are responsible for a part of the logic of a particular rule. These pieces and their logic are independent from each other but still they are able to communicate between each other by virtue of their inputs and outputs. The modules can be classified in three categories:

• Triggers – They trigger the execution of rules when an exact phenomenon occurs. A rule can have many triggers. Each one of them can independently trigger the rule. The Automation ESH module contains implementations for several types of triggers:
  • The time trigger requires an exact time to trigger a rule.
  • The event trigger requires an exact event to trigger a rule.
  • The sun position trigger requires an exact sun position to trigger a rule.
  • The functional item trigger requires an exact event to trigger a rule.
• Conditions – After being triggered, a rule's execution will continue only if all its conditions are satisfied. Conditions can be used to check the output from the trigger or other data. The Automation ESH module contains implementations for several types of conditions:
  • The time condition is satisfied before/after an exact time.
  • The sun position condition is satisfied before/after a given sun position.
  • The functional item condition is satisfied below/equal/above a given value.
  • The script condition is satisfied if the execution of the predefined script returns "true".
  • The "comparator" condition is satisfied if the comparison of the configured data succeeds. It can be used to compare two trigger outputs, or a trigger output and some pre-configured value.
• Actions – They describe the actual work that should be performed by a rule as a response to a trigger. The actions should be defined as short running task. The Automation ESH module contains implementations for several types of actions:
  • The functional item action can set some value to a functional item property or invoke an operation of a functional item.
  • The script action can execute a script.

The code responsible for the implementation of a module is called a Module Handler. The Automation ESH module provides a set of such handlers as well as the ability for the users to define their own and add them to the system. The handlers provide the logic responsible for the rules execution. The metadata describing this logic and how the modules communicate with each other is stored in Module Type definitions. These definitions can be provided as JSON files, or Java objects. The Automation ESH module contains a well systematized set of such JSON module definitions for the provided module types. For more details refer to the System Module Types guide.

Rule Templates

In order to facilitate the usage of existing modules as much as possible, there is also an ability to create and add rule templates. They are convenient if you want to have many rules with different configurations, that are composed of the same modules. They hide the complex details and export only the properties that must be configured.

Providers

The Automation ESH module contains System Providers that track bundle and system file resources for Module Types, Rules and Rule Templates.

REST API

The ESH-defined REST API simplifies the integration of the Automation ESH module with other systems or cloud services.

Admins API

The Bosch IoT SDK defines the Functional Item service as a general abstraction for representing different types of functionalities. It can be used for atomic functionality of:

• End Applications
• Cloud Services
• UI Business Logic

The Automation ESH module defines three Functional Item services:

• The Rule Admin service is a Functional Item wrapper of the Rule Registry. It exposes all Rule Registry's functionality as Functional Item operations. This enables the Bosch Cloud Services and Bosch Web UI Business Logic to work with Rule Registry in a general way. Its unique Functional Item ID is automation:rule:admin. The name of the Rule Admin as a Functional Item is Automation Rule Admin.
• The Module Type Admin service is a Functional Item wrapper of the Module Type Registry. It exposes all Module Type Registry's functionality as Functional Item operations. This enables the Bosch Cloud Services and Bosch Web UI Business Logic to work with Module Type Registry in a general way. Its unique Functional Item ID is automation:moduletype:admin. The name of the Module Type Admin as a Functional Item is Automation Module Type Admin.
• The Template Admin service is a Functional Item wrapper of the Template Registry. It exposes all Template Registry's functionality as Functional Item operations. This enables the Bosch Cloud Services and Bosch Web UI Business Logic to work with Template Registry in a general way. Its unique Functional Item ID is automation:ruletemplate:admin. The name of the Template Admin as a Functional Item is Automation Template Admin.

Web Console Plugin

The Automation ESH module contains a Web Console plugin that provides GUI for managing rules, rule templates and module types. It is based on the Admins API.