SAP Dynamic Edge Processing IoT Edge Console - Administration Guide Version 2.0 FP01

Transcription

1 SAP Dynamic Edge Processing IoT Edge Console - Administration Guide Version 2.0 FP01

2 Table of Contents ABOUT THIS DOCUMENT... 3 Glossary... 3 CONSOLE SECTIONS AND WORKFLOWS... 5 Sensor & Rule Management... 5 Sensor Profiles... 5 Rules & Rule Types... 6 Understanding how readings are processed by Dynamic Edge Processing... 7 Sensor Profile Scoping... 7 Rule Types... 8 Actions Configuration...12 Field Message Action Type...12 Sensor Fidelity Change Action Type...13 Work Order Creation...14 Real-Time Sensor Monitor...15 Live Devices...15 Emulator...15 Event History...16 Settings

3 ABOUT THIS DOCUMENT This administration guide provides a starting point for using the IoT Edge Console component of SAP Dynamic Edge Processing. It describes the primary features of the console. This document is intended for the following audiences: Consultants Partners Customers Glossary Term Definition Individual sensor profile Composite sensor profile Rule Numeric sensor value type State sensor value type Event Chainability Scoping Scope Level Scope Value Sensor Profile Device ID Device Tag Sensor ID Sensor Tag Tiering logic Real-Time Sensor Emulation Contains a set of properties pertaining to one sensor profile A location for chained rules to be specified User-defined logic applied to the sensor readings of a specified Sensor Profile Streams numeric sensor readings Streams non-numeric sensor readings Makes the rule available for composite rules Allows rules to only apply to readings from a sensor with specific properties, controlling how often a rule is applied A set of predefined attributes that can apply to the Device or the Sensor The value for the predefined Scope Level attributes A specific sensor profile A specific device based on a unique Device ID Device(s) with a specified Device Tag. Device Tags are a flexible mechanism allowing for arbitrary device level grouping. A specific sensor based on a unique Sensor ID Sensors with a specific tag, similar to the Device Tag scope The idea behind tiering logic is that more significant events imply less significant events, so that when the conditions for more significant events are satisfied, the less significant events do not fire. Displays all sensor profiles configured to Stream Readings to Monitor 3

4 Sensor Emulation Controls Allows you to emulate a stream of sensor readings for all sensor profiles 4

5 CONSOLE SECTIONS AND WORKFLOWS Sensor & Rule Management Users define and manage sensor profiles and their associated rules and actions in this section of the console. Sensor Profiles Sensor profiles describe the readings generated by a sensor. They also instruct Dynamic Edge Processing on how to interpret the readings in the context of rule evaluation. Every rule that is configured in Dynamic Edge Processing is created in the context of a sensor profile. For example, a user is interested in gathering readings from four separate sensors on a Model RF123 industrial refrigerator. There is one compressor temperature sensor, one door state sensor, and two internal temperature sensors. Both internal temperature sensors provide the readings using the same format and unit of measure. This scenario would require creating three sensor profiles in Dynamic Edge Processing. The compressor temperature sensor profile could be named RF123 Compressor Temp. The door state sensor profile could be named RF123 Door State. The internal temperature sensor profile could be named RF123 Internal Temp, and would be used for both internal temperature sensors. Note: The sensor profile name is user-defined and cannot be modified once it has been saved. Sensor profile names must be unique. Sensor profiles are also assigned a unique identifier when saved. Individual and Composite Sensor Profiles There are two types of sensor profiles, individual and composite. An Individual sensor profile contains a set of properties pertaining to one sensor profile (for example, Temperature or Refrigerator Door). Rules are defined against an individual sensor profile and are scoped to include only that sensor. Composite sensor profile is a location for chained rules to be specified looking for sensor readings coming from the same or different sensor profiles. For this reason, only individual sensors can be created. Numeric vs. State Sensor Value Type An individual sensor has two sensor reading value types, numeric and state. A numeric sensor value type streams numeric sensor readings. For example, a humidity sensor can stream relative humidity readings, or an electronic scale can stream live kilogram load. The following parameters need to be defined by the user: Testing & Production Parameters Minimum Value and Maximum Value for sensor readings. Determines the range for the Real-Time Sensor Monitor graphs and emulated controls. Window Parameters Window parameters are required on a per-sensor profile level and are used by rules that aggregate sensor readings. For example, the value monitoring rule uses the average sensor reading based on the window parameters. o Minimum # of Readings for Evaluation is the minimum number of sensor readings needed before averaging can be performed. This is useful for noisy analog sensors, for example, where trends are more important than individual readings. o Window Size is the length of time that sensor readings are kept for aggregation. Window size is recorded in seconds. The minimum window size is one second. Typically, window sizes would be 60 seconds or more. 5

6 A state sensor value type streams non-numeric sensor readings. For example, a door sensor could indicate whether the door is open or closed or an intelligent robot could report various movement states as it navigates a room. The following need to be defined by the user: State Values All possible values for sensor profile readings to stream to Dynamic Edge Processing along with an equivalent state name. For example, a traffic light could have state values 0,1,2 with the respective names, red, green, yellow. Stream Data to Monitor Toggles the streaming of sensor readings on and off to the Real-Time Sensor Monitor. Turning this on provides a view into the data streaming in Dynamic Edge Processing. This enables the viewing of graphs on the Real- Time Sensor Monitor. Tip: Monitoring this data has a negative effect on overall throughput. Turn this setting off except when conducting observation or troubleshooting. Configuring a Sensor Profile Following are the workflow steps to configure a sensor profile: [Tab: Sensor & Rule Management] 1. [Required] Click + to add a new individual sensor profile. 2. [Required] Enter a name for Sensor Profile Name. 3. [Optional] Enter a description for Sensor Profile Description. 4. [Optional] Select Stream Reading to Monitor to stream sensor readings to the Real-Time Sensor Monitor. 5. [Required] Select Numeric or State for Sensor Value Type. 6. [Required] Complete the additional required fields. 7. [Required] Save the Sensor Profile. Rules & Rule Types A rule is user-defined logic applied to the sensor readings of a specified sensor profile. When a rule is satisfied, it triggers an event or controls the fidelity of IoT sensor data. Several built-in, configurable Rule Types are supported natively by Dynamic Edge Processing along with the option to build custom rules. To create a rule you must first define the logic used to determine that a certain event has occurred. You configure where these events are sent by specifying destinations within the rule. Destinations include the edge database and any number of available enterprise plugins. This allows you to notify services that the event has occurred. In addition, you can set one or more actions to be performed every time the event occurs. For more information on actions, refer to the Action Configuration section. You create rules within sensor profiles, but they can be applied to a variety of scopes. They are also uniquely defined for the sensor profile they belong to. Rules can also be enabled or disabled by the administrator. A rule contains the following sections: [Required] General Information o Rule Name o Rule Description o Event Chainability (Y/N) This makes the rule available for Chained Rules [Required] Rule Definition: Rule-specific attributes to define rule logic. Currently one global parameter is required: 6

7 o [When applicable] Max Event Frequency: Events trigger every time an associated sensor reading fulfils the requirements of the rule. Consider a temperature sensor that has risen to 90 degrees Celsius and remains that way. A value monitoring rule that triggers an event when the average sensor reading is over 80 degree Celsius will fire constantly while the reading remains at 90 degrees. The Max Event Frequency controls how frequently an event occurs. For this event to be triggered hourly, for example, you would set the minimum time between events to 1 hour. [Optional] Event Actions: Associated actions applied to triggered events of the rule. [Optional] Event Destination / Sensor Readings Destination: o Enterprise plugin(s): Associate enterprise plugins. This enables Dynamic Edge Processing to move events to any backend system, provided that a plugin is configured or written to move the data. Refer to the SAP Dynamic Edge Processing: IoT Edge Services - Configuration Guide for information on creating plugins. o Edge Event Storage: Specify events to be stored in Dynamic Edge Processing edge storage. Edge Keep Interval (days): Specify how long events are kept in edge storage Note: Rule names are user-defined and cannot be modified once they are saved. Rule names are uniquely defined for the sensor profile they are associated with. Rules are also assigned a unique identifier when saved. Understanding how readings are processed by Dynamic Edge Processing One or more readings can be sent to Dynamic Edge Processing at a time. All readings are sent within the context of a device. Each device has a unique device ID and readings are considered within the context of this device ID. A device can have a Device Tag, which is used to arbitrarily group devices. For example, a device tag of Outside Temperature could be applied to all devices. Note: Device tag does not affect how data is aggregated. Each reading must contain a sensor profile ID or sensor profile name and a reading value. It may also contain a sensor ID, sensor tag, context, and timestamp. Tags are used in the devices and sensor profiles to provide a flexible form of grouping. Sensor Profile Scoping Scoping allows rules to only apply to readings from a sensor with specific properties, controlling how often a rule is applied. There are two components to scoping: Scope Level and Scope Value. Scope level is a set of predefined attributes that can apply to the device or the sensor. Scope value is the value for the predefined Scope Level attributes. In any rule, the scope value chosen for a scope level must correspond to a real device or sensor for the rule to apply. The rule is applicable to readings for the following scope levels: Sensor Profile: A specific sensor profile Device ID: A specific device based on a unique Device ID Device Tag: Device(s) with a specified device tag. Device Tags are a flexible mechanism allowing for arbitrary device level grouping. For example, a rule could be scoped for the Second Floor Device Tag. This rule would only trigger for devices with that device tag. Sensor ID: A specific sensor based on a unique sensor ID. This is the most specific scoping level. Sensor tag: Sensors with a specific tag, similar to the device tag scope. For example, you can use sensor tag scoping to apply a rule to all humidity sensors tagged as Second Floor. For detailed information on Composite Sensor Profile Scoping, see Creating an Event Chaining Rule. 7

8 Tiering Logic The idea behind tiering logic is that more significant events imply less significant events, so that when the conditions for more significant events are satisfied, the less significant events do not fire. When a reading is produced by a sensor, only the most significant rule that is satisfied will be triggered and will generate an event. For example, suppose a temperature sensor has two numeric comparison rules, one for greater than 60 degrees and one for greater than 80 degrees. If the sensor produces a reading of 65 then the first rule will be triggered. However, if it produces a reading of 85 only the second rule will be triggered, because it is the most significant and it implies that the condition for the first rule is also passed. Tiering logic is only applied to rules within the same scope, and in the case of value monitoring, rules with the same threshold operator. For example, a Temperature sensor profile has two value monitoring rules, Rule 1 and Rule 2. Rule 1 is for greater than 60 degrees and Rule 2 is for greater than 80 degrees. Rule 1 is scoped by Device Tag with a value of Rig 1, and Rule 2 is scoped by Device ID with a value of MH01. If the sensor produces a reading of 85, that meets both scope criteria (i.e. the reading came from a Temperature sensor that is part of a device with Device Tag having a value of Rig 1 and Device ID having a value of MH01 ), both rules would trigger events because each of the rules have a unique scope level and scope value. Rule Types Several built-in, configurable rule types are supported natively by Dynamic Edge Processing. They allow users to easily define rules based on common event processing patterns, without the need for development work. If the provided rule types do not fit the desired logic, there is an option to create and use an external custom rule. Sensor Fidelity Rules Sensor fidelity rules are unique in that they do not generate events, but rather they control the frequency at which readings from the sensor are outputted to the edge storage or enterprise endpoints. Note: This rule type is valid for both numeric and state sensor value types. Characteristics/Attributes: Edge sensor data can be pulled to the Enterprise for analysis upon request. For example: pressure gauge readings are streamed every 500ms. The edge receives a reading every 5 seconds, and the enterprise backend receives a reading hourly. Higher fidelity data can be pulled from the edge if there is a problem. Only one sensor fidelity rule can be enabled on a sensor at any point in time. Note: Refer to the Sensor Fidelity Change Action Type section for information on the option to change the Sensor Fidelity when specific events occur. Rule-Specific Attributes: Edge Output Frequency: The frequency at which sensor readings should be outputted to the edge storage location. You can use a REST API to access the edge data. Enterprise Output Frequency: The frequency at which sensor readings should be outputted to the enterprise location. Creating a Sensor Fidelity Rule Following are the workflow steps to configure a sensor profile: [Tab: Sensor & Rule Management] 1. [Required] Under a Sensor Profile, click + in the Rules table. 2. [Required] Complete the required fields and save. 8

9 Note: Only one enabled Sensor Fidelity Rule is allowed. Value Monitoring Rule Type Uses the sensor profile s configurable time window settings to monitor a sensor s average reading value. Note: This rule type is only valid for numeric sensors. Characteristics/Attributes: Applies to numeric sensor data Average values can be monitored for: o Exceeding a threshold value > o Going below a threshold value - < Equality to a specified value with a configurable bidirectional tolerance. For example: an Average Temperature Sensor has gone over 90 C, with a minimum of five readings over a time window of 5 seconds. Note: Value monitoring rules apply tiering logic for each operator type individually (equality rules are exempt from tiering). For greater than rules, the most significant rule is the one with the greatest threshold value. For less than rules, the most significant rule is the one with the lowest threshold value. Rule-Specific Attributes: o Threshold Value: positive and negative values accepted o Threshold Operator: Greater Than, Less Than, Equal To (optional tolerance) Creating a Value Monitoring Rule Following are the workflow steps to create a value monitoring rule: [Tab: Sensor & Rule Management] [Required] Under a Sensor Profile, click + in the Rules table. [Required] Complete the required fields and save. Timed State Rule Type Used to determine if a sensor has been in a specified state for a configured amount of time. For example, a door sensor has been in the Open state for five minutes. Note: This rule type is only valid for state sensor value types. Characteristics/Attributes: Timed state rules apply tiering logic, where the rule with the longest time in state is considered the most significant. o Rules with a time in state of 0 are exempt from tiering. These rules will fire every time the state is read. Note: Timed state operates on an on-demand basis: computations are only done (and events are triggered) only when a new reading comes in. Consider a door sensor with open and closed states. If an open reading comes in and then a closed reading comes in 15 seconds later, it is assumed that the sensor was in the open position for those 15 seconds (up until the time the closed reading arrives) and events are fired accordingly. No events will be triggered in the time between readings (assuming there were no other readings for the corresponding sensor). Rule-Specific Attributes: 9

10 Target State: This is the state the rule is looking for. Time in State: The minimum length of time the sensor is in the target state. One reading from another state will reset the timer. Creating a Timed State Rule Following are the workflow steps to create a value monitoring rule: [Tab: Sensor & Rule Management] 1. [Required] Under a Sensor Profile, click + in the Rules table. 2. [Required] Complete the required fields and save. Sensor Watchdog Rule Type Used to determine if a sensor has a gone silent for a configurable period of time. For example, when a motion detector has not streamed data for 15 minutes. Note: This rule type is valid for both numeric and state sensor value types. Characteristics/Attributes: Sensor watchdog rules apply tiering logic, where the rule with the longest time since last reading is considered the most significant. Sensor watchdog automatically runs every second once a sensor has sent its first reading and continues to run for the lifetime of the current Dynamic Edge Processing session. Rule-Specific Attributes: Max Interval Without Reading: Length of time passed without a sensor reading Creating a Timed State Rule Following are the workflow steps to create a timed state rule: [Tab: Sensor & Rule Management] 1. [Required] Under a Sensor Profile, click + in the Rules table. 2. [Required] Complete the required fields and save. Event Chaining Rules A composite sensor profile is used to chain two events together. Note: This rule type is valid for both numeric and state sensor value types. Characteristics/Attributes: Two rules are chained at a time. Rules created by individual sensor profiles must have the Event Chainability field enabled. Event chaining rules themselves can also be chained. Looks for two events to occur within a configurable period of time of each other, for example a worker s motion sensor has reported the Fallen state within 60 seconds of a High Gas Levels event. Scoping is as follows: o Device Wide 10

11 o The Chained Rule s Events must occur on the same device ID. For example: Rule 1, Temperature High, and Rule 2, Door Open, have been chained and scoped to Device Wide. Conditions for Rule 1 are met on device ID Fridge 105 and Rule 2 on device ID Fridge 106. As the events have not occurred on the same device ID, the chained rule is not triggered. However, when conditions for both rules are met on the same device ID, the chained rule is triggered. Device ID The chained rule s events must occur on the specified device ID, which is the only device ID that can trigger the event. For example: Rule 1, Temperature High, and Rule 2, Door Open, have been chained and scoped to Device ID of Fridge123. Conditions for Rule 1 and Rule 2 are met on device ID Fridge 789. As the events have not occurred on the specified device ID, the chained rule is not triggered. However, when conditions for both rules are met on the sevice ID Fridge123, the chained rule is triggered. Rule-Specific Attributes: Rule Name 1: First unique chainable rule selected. The selection list includes only chainable rules. Rule Name 2: Second unique chainable rule selected. The selection list includes only chainable rules. Time Gap: The maximum time allowance between the two chained events. Event Ordered: Specify whether events need to occur in the specified order of rule selection, i.e.: Rule 1 before Rule 2. When not selected, the rule looks for the two events to occur within the time gap, regardless of order. Creating an Event Chaining Rule Following are the workflow steps to create an event chaining rule: [Tab: Sensor & Rule Management] [Required] Under a Sensor Profile, click + in the Rules table heading to create Rule 1. [Required] Complete the required fields, make sure the Event Chainability option is selected, and save this Rule. [Required] Follow steps 1 and 2 to create Rule 2. [Required] Under Composite, click + in the Chained Rules table heading to create an Event Chaining Rule. [Required] Complete the required fields to save the Event Chaining Rule. Note: Event Chaining Rules themselves can also be chained. External Custom Rule Allows developers to define their own rule logic and events. Note: This rule type is valid for both numeric and state sensor value types. Characteristics/Attributes: Custom rules can be written in a separate Streaming Lite project Template project and examples are provided Integrates back into the framework o Events can be sent to the edge and enterprise endpoints o Events can have actions associated to them 11

12 o Scoping and Max Event Frequency are handled by Dynamic Edge Processing, not the external custom rule logic Creating an External Custom Rule Refer to the SAP Dynamic Edge Processing: IoT Edge Services Developer Guide for creating CCL projects. Enabling and Disabling Rules Rules can be enabled and disabled as required (rather than being deleted and added). Event Actions Actions are automated, user-configured responses to events generated by rules. One or more actions can be associated to a rule. For detailed information on Actions, refer to Actions Configuration. Event Destination & Sensor Readings Destination Enterprise Plugins Define the enterprise destination(s) for the events generated by a rule. Enterprise destinations are defined in the enterprise plugin configuration. Refer to the SAP Dynamic Edge Processing: IoT Edge Services - Configuration Guide. Edge Event Storage Controls whether events are stored locally in the edge database. Edge Keep Interval Specify the length of time to store events in the edge database. Actions Configuration Use this section of the console to configure and manage actions. Actions are automated responses to events generated by rules. These actions are executed whenever their associated event(s) occur. One or more configurable actions can be associated to a rule. Supported action types include: Field Message Sensor Fidelity Change Work Order Creation Field Message Action Type Sends a Message to a specified Protocol Plugin Can be used for sending messages and actuation instructions to devices The target protocol plugin is responsible for transmitting message to devices o The protocol plugin must support outbound messages The Protocol Plugin is responsible for formatting the outbound message. For example, when a High Gas event occurs, use an MQTT Protocol plugin to broadcast the message Evacuate Area 4 Immediately to all workers. Action-Specific Attributes: Plugin ID The protocol plugin that receives the message. Message Free-form text sent to the protocol plugin. Usage is specific to the protocol plugin. Recipient Parameters 12

13 Free-form text sent to the protocol plugin. Usage is specific to the protocol plugin. The protocol plugins that are included with Dynamic Edge Processing handle field messages in the following manner: MQTT: Sends a message to the configured topic. The message body is a JSON formatted object including all available properties: o Device ID o Device Tag o Sensor Profile ID o Sensor Profile Name o Sensor ID o Sensor Tag o Timestamp (The timestamp of the sensor reading that triggered the event) o Source Rule ID (The ID of the rule that triggered the event for the field message) o Source Rule Name (The name of the rule that triggered the event for the field message) o Instruction o Parameters Refer to the SAP Dynamic Edge Processing: IoT Edge Services - Configuration Guide for the specific JSON format. HTTP: (Only supported for clients connected via the Websocket protocol not supported for clients connected via REST). Sends a message to all connected clients. The message body is a JSON formatted object including all available properties: o Device ID o Device Tag o Sensor Profile ID o Sensor Profile Name o Sensor ID o Sensor Tag o Timestamp (The timestamp of the sensor reading that triggered the event) o Source Rule ID (The ID of the rule that triggered the event for the field message) o Source Rule Name (The name of the rule that triggered the event for the field message) o Instruction o Parameters Refer to the SAP Dynamic Edge Processing: IoT Edge Services - Configuration Guide for the specific JSON format. Tip: Field message actions are a quick and effective way to test rules and validate the end-toend flow. You can test specific rules in a controlled emulation environment, as opposed to monitoring the Event History screen, which logs all events fired by any rule. The Emulator is implemented as a Websocket client to the HTTP protocol plugin. In order to see field messages in the emulator, create a field message action that specifies the plugin ID as HttpProtocolPlugin. Sensor Fidelity Change Action Type Changes the edge and enterprise output frequencies for a sensor profile. Only applicable to sensor profiles with an enabled sensor fidelity rule. 13

14 Changes are optionally rolled back to original frequencies after a configurable period of time. For example: When the Average Temperature goes above 90 C, increase the enterprise sensor fidelity frequency to every 5 seconds for the next hour (rollback in effect). When the average temperature goes above 90 C, increase the enterprise sensor fidelity frequency to every 5 seconds. (rollback not in effect). Restarting Dynamic Edge Processing resets all sensor fidelity rules to their original frequencies, regardless of the sensor fidelity change action that was previously applied. If two sensor fidelity change actions are created and applied to the same target sensor profile, the one that occurred most recently will be in effect. Tip: Multiple sensor fidelity change actions can be applied to the same sensor profile. This allows the user to configure a sensor fidelity increase on a certain event and also configure a sensor fidelity decrease on a separate event. For example, assume the enterprise sensor ffdelity Frequency is configured to 60 seconds. When the average temperature goes above 90 C, increase the enterprise sensor fidelity frequency to every 5 seconds (rollback not in effect). When the average temperature goes below 90 C, decrease the enterprise sensor fidelity frequency to every 60 seconds (rollback not in effect). Action-Specific Attributes: Target Sensor Profile This list only pulls the sensor profiles that have a sensor fidelity rule enabled. Edge Fidelity Change Specify the new frequency (s) and the rollback time period (s) (if desired) for the edge storage destination. A value of 0 prevents a rollback. Any frequency changes due to edge fidelity change are reset to original values when Dynamic Edge Processing is restarted. Enterprise Fidelity Change Specify the new frequency (s) and the rollback time period (s) (if desired) for the enterprise destination. A value of 0 prevents a rollback. Any frequency changes due to enterprise fidelity change are reset to original values when Dynamic Edge Processing is restarted. Work Order Creation This feature must be configured. Refer to the SAP Dynamic Edge Processing: IoT Edge Services - Configuration Guide. This Action uses an external Dynamic Edge Processing core to edge server to automatically create a plant maintenance (PM) work order. The required fields for the work order are configured based on the local Dynamic Edge Processing edge business services implementation. This ensures the required fields are valid for the local environment. When a work order is initially created, it creates a new work order in edge business services. If the work order is being created again, edge business services checks to see if the work order already exists, and if it does, it adds a note to the work order, rather than creating a new one. For example, when a piece of equipment has not streamed a water level sensor reading for four hours, create a maintenance work order to have it repaired. Refer to the SAP Dynamic Edge Processing: Edge Business Services - API Guide for specific field requirements. 14

15 Real-Time Sensor Monitor Use this section of the console to monitor sensor readings from live devices and other sources and test rules in an emulated environment. Live Devices Sensor profiles configured to Stream Readings to Monitor appear under the device ID in the Live Devices. Graphs will not appear if sensor readings are not streaming through Dynamic Edge Processing. Emulator You can test end-to-end rule logic using the built-in emulated device and emulated sensor controls. The Real- Time Sensor Emulation view displays all sensor profiles configured to Stream Readings to Monitor. The Sensor Emulation Controls panel allows you to emulate a stream of sensor readings for all sensor profiles. The Sensor Emulator only sends readings when it has been started. Each sensor profile control allows you to modify the sensor values sent through Dynamic Edge Processing in real time. In addition, you can configure device ID, device Tag, sensor ID, and sensor tag for the purpose of testing rule scoping. You can only edit these when the sensor emulator is stopped. You can enable or disable sensor profiles using the Settings button on the panel. Disabled sensor profiles do not show up as a control and therefore do not stream any readings through Dynamic Edge Processing. Use the slider to control numeric sensor profile values. The standing value is always streamed first, even if it has not been modified. For example, a temperature sensor with a range of -40 to 100 will initially stream a value of -40. The range of the slider is determined by the range specified in the sensor profile. State sensor profile values are controlled by a collection of buttons. The selected state is streamed through Dynamic Edge Processing until it is unselected or the selection is changed. If no selection is made, no value is streamed. Note: The emulator streams the current sensor readings once every second. Triggered Field Messages The instructions for the field message action are displayed along with the name of the triggering sensor profile. Tip: Field message actions are a quick and effective way to test rules and validate the end-to-end flow. You can test specific rules in a controlled emulation environment, as opposed to monitoring the Event History screen, which logs all events fired by any rule. The emulator is implemented as a Websocket client to the HTTP Protocol Plugin. In order to see field messages in the emulator, create a field message action that specifies the Plugin ID as HttpProtocolPlugin. Readings are always considered within the context of a device ID, even if they are not scoped by a device ID. For this reason, the emulator initially generates an emulated device ID. For example, if there are two users using the emulator at the same time, two distinct emulated device IDs are generated to prevent overlap. As Dynamic Edge Processing does not differentiate between emulated devices and live devices, other users emulated devices show up under Live Devices, the exception being the current user s emulated device, which shows up under Emulated Device. 15

16 Note: SSL configuration If a self-signed certificate is used for the emulator that differs from the self-signed certificate used by Dynamic Edge Processing s NodeJS web server, the certificate used by HTTPProtocolPlugin needs to be trusted by the browser for the emulator to successfully stream readings to Dynamic Edge Processing. Refresh the page from the Devices list to see latest changes made to sensor profiles. Event History Use this section to view a log of all triggered edge events that have been configured to be saved on the edge. When creating a rule, Edge Event Storage must be selected under the Event Destination section. Settings Use the Settings section of the console to change the sole user account s password. There is no multi-user configuration and management in this version of Dynamic Edge Processing. 16

17 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. Please see for additional trademark information and notices. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation, and SAP SE s or its affiliated companies strategy and possible future developments, products, and/or platform directions and functionality are all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.