How we enjoy with Edge X October 5

How we enjoy with Edge. X. October 5, 2017 Samsung Electronics. edgexfoundry. org | @edgexfoundry

LF Antitrust Policy Notice Edge. X Foundry meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Examples of types of actions that are prohibited at Edge. X Foundry meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at http: //www. linuxfoundation. org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation. edgexfoundry. org | @edgexfoundry

Agenda • • OPC UA microservice Edge Messaging Framework Service Deployment Data Processing Framework edgexfoundry. org | @edgexfoundry

OPC UA Microservice (1/3) • OPC UA microservice is one of the device services. • It is based on the open source, ‘milo’ • https: //github. com/eclipse/milo • Eclipse Public License v 1. 0 • Written in Java. • The data between edge device and machine can be transferred over OPC UA. • The edge device can convert data from PLC and other proprietary protocol to the OPC UA edgexfoundry. org | @edgexfoundry Data Analytics Data Computing Edge Device OPC UA Data Acquisition Data Collecting Edge Device PLC . . . BLE Machine / Robot / Sensor

OPC UA Microservice (2/3) • OPC UA server / client functions is going to be provided with separate microservices. • Features ( from OPC UA specification ) • Attribute Service ( Read / Write ) • Data Access • Subscription Service ( Create / Modify / Republish ) • View Service • Address Space Model Generator • Reference : https: //opcfoundation. org/developer-tools/specifications-unifiedarchitecture/ edgexfoundry. org | @edgexfoundry

OPC UA Microservice (3/3) • UPC UA foundation CTT will be passed • about 250 test cases for client • about 620 test cases for server • The microservice implementation will be completed until Oct. 30 • Samsung QA team will be verified • OPC UA in C is considered based on open 62541 • https: //open 62541. org/ • Mozilla Public License v 2. 0 edgexfoundry. org | @edgexfoundry

Edge Messaging Framework (1/3) • Background • to guarantee the real-time data transmission from device service to any microservices. • Microservice can get the data from ‘CORE DATA’, but it is not real-time. • Current Edge. X doesn’t provide generic interface between microservices. • ØMQ, Active MQ used for specific microservices (eg ‘CORE DATA’ ‘DISTRIBUTION’) ØMQ usage in Edge. X • for rapid data processing, direct messaging scheme is required from the Device Services to the Supporting/Export Services • For the future, data can be passed via multiple edge devices. So efficient messaging scheme should be designed. • Topic based broker service is one of the candidates edgexfoundry. org | @edgexfoundry

Edge Messaging Framework (2/3) • Features • Share streaming data either directly between micro services or on topics shared across an edge cluster. • Provide API’s (EMF client library) to stream reliable or regular data. • Provide API’s (EMF client library) to abstract highly efficient and standardized serialization and deserialization of data to be shared between MS regardless of language or platform used to develop MS • Current status • EMF client library in C++ and Java (completed) • EMF client library in Go. Lang (10/20) • EMF microservice in export service (12/15) edgexfoundry. org | @edgexfoundry

Edge Messaging Framework (3/3) • Functional Component • EMF Library Module View • Deployed Location: Inside micro services as jar /. so. • Role: Interface for all data streaming requirements, serialization / de-serialization of data, direct streaming to other MS. • EMF Microservice • Deployed Location: On each Edge Device. • Role: Facilitate data delivery on topics, across edges and for reliable data handling. Clone reliable data across edge devices for guaranteed delivery in case of edge device failure edgexfoundry. org | @edgexfoundry

Service Deployment • Requirements • Operator can deploy an application container(s) to a specific Edge device • Operator can run, pause, resume, stop the specific container(s) already deployed in a certain Edge device. • Operator update and delete a deployed container(s) as intended in a certain Edge device. • Operator can deploy/update/delete container(s) to a group of Edge devices at one time. • To do so, a group of Edge devices might be managed in a certain Edge device. edgexfoundry. org | @edgexfoundry

Service Deployment • Features • For management of microservice • • Deploy a container to an Edge device or a group of Edge devices. Create and delete a group of Edge device Add and remove an Edge device to/from a group of Edge devices Provides a healthy status(i. e Not. Ready/Ready) of all registered Edge devices • To run/monitor of microservice • • Docker operations for container management by utilizing “docker-compose” languages Request a registration to an Edge server for centralized management of service deployment Send a periodic ping request for its availability to a master Failover for a case where a running container is unexpectedly terminated edgexfoundry. org | @edgexfoundry

Service Deployment • Functional Components • Microservice deployment master • Deployed location: a centralized Edge server • Role: Edge device group management, service deployment propagation to each Edge device Docker • Microservice deployment slave • Deployed location: Every edge device • Role: Perform container installation, update, and termination as requests by master edgexfoundry. org | @edgexfoundry RESTful API (Deploy, update, etc) Edge Mgmt. Server Microservice deployment master Operator / Administrator RESTful API (Deploy, update, etc) Registry Edge Device #1 Service #1 Docker image Download Service #2 Edge Device #2 Microservice Deployment Slave (Container) Docker Engine docker-compose Service #1 Service #2 Microservice Deployment Slave (Container) Docker Engine

Service Deployment • Implementation • Slave container utilizes “docker-compose” tool to deploy containers • In case of new container(s) installation • docker-compose YAML description should be delivered in a body of HTTP request • written in Go. Lang • Scheduled features are going to be completed until 10/31 • Issue : compatibility with kubernetes edgexfoundry. org | @edgexfoundry

Service Deployment – Kubernetes • docker-compose vs. Kubernetes • Kubernetes: an well-known open-source project for container-based service orchestration commonly used in Cloud (Link: https: //kubernetes. io/) Docker-compose Pros Cons - No overhead and performance degradation to edge device and running containers Suitable to existing Edge. X service architecture - Service deployment should be manually performed on each of edge devices Provide automated deployment, scaling, and management of containers regardless of location of edge devices User does not have to consider where containers are deployed Provide communications between multiple edge devices (utilizing overlay network) - Produce an computational overhead in running Kubernetes, which may be significant to resource-constrained edge device like Raspberry Pi Enlarge an communication latency between containers hosted in difference edge devices, which is expected to happen frequently. Hard to form Kubernetes cluster of multiarchitecture edge devices (e. g. x 86_64, Kubernetes - edgexfoundry. org | @edgexfoundry - -

Service Deployment – Issues of Kubernetes • Two S/W Architectures CAN be formed as below with Kubernetes • Arch. #1: Keep the current Edge. X Architecture (exploiting “Node. Selector”) • Arch. #2: Deploy each services as Kubernetes really wants to do • Kubernetes automatically deploys containers to the most affordable node based on its capability (remaining CPU, RAM) Edge #1 Exporting Service Supporting Service Core Service Device Service Architecture #1 edgexfoundry. org | @edgexfoundry Edge #2 Device Service Architecture #2 - Device/Supporting services and Core/Exporting services are deployed in Edge#1 and Edge#2, respectively

Service Deployment – Issues of Kubernetes • Issues - Architecture #1 • Can not exploit Kubernetes’s features at all except only deployment • No scale up/down of the number of pods of a service for the service’s reliability • e. g. Each of Core services should be running in every Edge device (no need of scaling) • No load balance between pods of a service • e. g. core data service in Edge #1 should communicate with export service in same Edge, not one in different Edge • No automated deployment based on node’s capability • Has to know the target Edge device’s IP address to deploy a container edgexfoundry. org | @edgexfoundry Edge #1 Exporting Service Supporting Service Core Service Device Service Arch #1

Service Deployment – Issues of Kubernetes • Issues - Architecture #2 Edge #1 • No use of “localhost” address Exporting Service • No guarantee the target container are running in a same Edge device • Instead, domain name of service should be used • E. g. • Core data : core. svc. cluster. local • Meta data : meta. svc. cluster. local Edge #2 Supporting Service Core Service Device Service Arch #2 e. g. https: //github. com/edgexfoundry/devicesdk/blob/master/src/main/resources/rest-endpoint. properties #---------- REST Endpoints -------------------# Edge. X metadatabase service connection information meta. db. addressable. url=http: //localhost: 48081/api/v 1/addressable. . . #---------- REST Endpoints -------------------# Edge. X metadatabase service connection information meta. db. addressable. url=http: //meta. svc. cluster. local: 48081/api/v 1/addressable. . . #Edge. X core database service connection information core. db. event. url=http: //localhost: 48080/api/v 1/event #Edge. X core database service connection information core. db. event. url=http: //core. svc. cluster. local: 48080/api/v 1/event edgexfoundry. org | @edgexfoundry

Service Deployment – Issues of Kubernetes • Issues - Architecture #2 (cont’) • A container should be implemented to be STATELESS • “State” means an configuration which can effect a behavior or result of container • A certain rule engine service, a mathematic model in data analytic service • A container could be replicated to multiple instances for its better availability so all of replicated container should be operated in a same way. (returns a same result) • If a container is stateful, a replicated container can perform in a different way to other replications because some configurations • No use of “consul” for registry&configuation service • Instead, “etcd” is supported by Kubernetes edgexfoundry. org | @edgexfoundry

Data Processing Framework (1/3) • Characteristics of the Industrial Data Factors Description Frequency of Events Low Quantity of Event Sources Large (ex: Machines, Sensors, etc) Influencing Factors in Event Various Cost of Events Large (ex: Productivity decreases) (ex: Machine may rarely malfunction) • Requirements 1. 2. 3. 4. All the anomalies should be detected based on the historical data collected while machine worked properly All the anomalies should be detected regardless of number of anomaly influencing factors All the sources which could emit anomaly events should be monitored at the same time All the anomalies should be detected in real-time or before-hand in order to minimize the resolving costs edgexfoundry. org | @edgexfoundry

Data Processing Framework (2/3) • Features • Data Processing Algorithm Set (Req. 1, 2) • Provides various data connectors & algorithms for pipeline creation • Connectors : Database, EMF, etc. • Algorithms : Data ETL(extract, transform, load), Analytics, Query and etc. • Data Processing Pipeline Runtime (Req. 3, 4) • Executes multiple data processing pipelines in parallel manner • Data Processing Pipeline Design • Provides intuitive way of creating & deploying the data processing pipeline • Visual Programming Tool edgexfoundry. org | @edgexfoundry

Data Processing Framework (3/3) • Status • Data Processing Algorithm Set • Connector : 1 connector (EMF) • Deliver : 3 delivers (EMF, File, Web. Socket) • Algorithm : 11 (Linear/Logistic Regression & etc) • Data Processing Pipeline Runtime • Stream Processing Feature : Apache Flink • Plan • Data Processing Algorithm Set (~’ 18. 10) • Extends Connector/Deliver/Query/ETL/Statistics and Machine Learning Algorithms • Data Processing Pipeline Runtime (~’ 18. 6) • Add Continuous Query(CQ) Processing Feature • Data Processing Pipeline Design (~’ 18. 10) edgexfoundry. org | @edgexfoundry Sequence

Appendix edgexfoundry. org | @edgexfoundry

ØMQ usage in Edge. X edgexfoundry. org | @edgexfoundry

Edge Messaging Framework • Architecture view EMF Library EMF Microservice EMF API Subscriber Streams Filter Publisher Streams Topic PORT Topic Serializer Regular Data Streams Reliable Data Streams Data Sync Data Store IP: PORT De. Serializer ØMQ / MQTT Topic Stream Router Multi Edge Streaming Edge Handshake Discovery ØMQ / MQTT Cluster Protobuf ØMQ / MQTT Modules to be developed edgexfoundry. org | @edgexfoundry External Component

Data Processing Framework - Service Seq. : EMF : Micro Service : Internal Dataflow : Algorithm : Pipeline Edge Device Data Processing Pipeline Design Tool Design pipelines with Tool & Deploy them to engines DB Connector EMF Connector Edge Device X (Storage Edge) Edge Device Y (Processing Edge) Regression *LSE Interpolation Filtering Regression Runtime Manager Algorithm Storage User Data Processing Runtime deliver LSE Pipeline Scheduler Manage life-cycle of pipelines RESTful API (create, execute, update, delete & etc) Interpolation EMF Connector Filtering Engine Controller Deploy pipelines directly to engine Pipeline Storage Abstractor Flink Interface XXX Interface … Apache Flink XXX … Historical Data Operational Data EMF edgexfoundry. org | @edgexfoundry *LSE : Least Square Estimation (Algorithm) DB Connector EMF Connector