How we enjoy with EdgeX.

1. How we enjoy with EdgeX. October 5, 2017 Samsung Electronics.

2. LF Antitrust Policy Notice EdgeX 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 EdgeX 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.

3. Agenda • OPC UA microservice • Edge Messaging Framework • Service Deployment • Data Processing Framework

4. 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 v1.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 Data Analytics Data Computing Edge Device OPC UA Data Acquisition Data Collecting Edge Device PLC . . . BLE Machine / Robot / Sensor

5. 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-unified-architecture/

6. 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 the • OPC UA in C is considered based on open62541 • https://open62541.org/ • Mozilla Public License v2.0

7. 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 time. • Current EdgeX doesn’t provide generic interface between microservices. • ØMQ, Active MQ used for specific microservices (eg ‘CORE DATA’  ‘DISTRIBUTION’) • 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 ØMQ usage in EdgeX

8. 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 GoLang (10/20) • EMF microservice in export service (12/15)

9. Edge Messaging Framework (3/3) • Functional Component • EMF Library • 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 Module View

10. 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.

11. 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.eNotReady/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

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

13. 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 GoLang • Scheduled features are going to be completed until 10/31 • Issue : compatibility with kubernetes

14. 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/)

15. Service Deployment – Issues of Kubernetes • Two S/W Architectures CAN be formed as below with Kubernetes • Arch. #1: Keep the current EdgeX Architecture (exploiting “NodeSelector”) • 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 Edge #1 Edge #2 Exporting Service Exporting Service Supporting Service Supporting Service Core Service Core Service Device Service Device Service Architecture #2- Device/Supporting services and Core/Exporting services are deployed in Edge#1 and Edge#2, respectively Architecture #1

16. 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 servicefor the service’s reliability • e.g. Each of Core services should be runningin 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 withexport 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 addressto deploy a container Edge #1 Exporting Service Supporting Service Core Service Device Service Arch #1

17. Service Deployment – Issues of Kubernetes • Issues - Architecture #2 • No use of “localhost” address • 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 #1 Edge #2 Exporting Service Supporting Service Core Service Device Service Arch #2 e.g. https://github.com/edgexfoundry/device-sdk/blob/master/src/main/resources/rest-endpoint.properties #------------------- REST Endpoints --------------------------------------- # EdgeX metadata database service connection information meta.db.addressable.url=http://meta.svc.cluster.local:48081/api/v1/addressable ... #EdgeX core database service connection information core.db.event.url=http://core.svc.cluster.local:48080/api/v1/event #------------------- REST Endpoints --------------------------------------- # EdgeX metadata database service connection information meta.db.addressable.url=http://localhost:48081/api/v1/addressable ... #EdgeX core database service connection information core.db.event.url=http://localhost:48080/api/v1/event

18. 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 in 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

19. Data Processing Framework (1/3) • Characteristics of the Industrial Data • Requirements • 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

20. 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

21. Data Processing Framework (3/3) • Status • Data Processing Algorithm Set • Connector : 1 connector (EMF) • Deliver : 3 delivers (EMF, File, WebSocket) • 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) Sequence

22. Appendix

23. ØMQ usage in EdgeX

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

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