Current MVP Thoughts from each WG Core MVP Discussion Current MVP Thoughts from each WG

MVP Discussion Current thoughts about MVP in each area (keep it high level today) What are the emerging MVP What are the issues/constraints & likelihood complete by Barcelona Resource needs (people, equipment, etc.) Starting with bottom working to top South end - DS / DS SDK Core/Supporting services Application – Export Services/Analytics/Rules Engine Test/QA/Build/CI

FYI - Current Performance Targets Barcelona to be built for “forgiving” use cases Targets All services run in 2GB or less memory (RAM) All services (the “system”) comes up in 2-3 minute start/boot time (not including OS) Latency times must be within the following and need to be predictable 300ms from capture to export 500ms from capture to actuation

Release names As we “bucketize” the work into releases, for the sake of argument right now… Barcelona – Fall 2017 (Oct 1-3) California – Spring 2018 (target Feb / Mar conferences)

Device Services/ SDK Tony Espy

Device Services SDK MVP Review current code generation approach ~40 template classes copied to new DS, many unchanged Re-factor to: reduce duplicated code across DSes Review Spring Frameworks usage Harden code (per Core Service recommendations) Basic Eclipse integration (ie. no more cmd-line required)

Device Services SDK – Known Issues Minimal documentation, missing javadoc Builtin Device Scheduler Clock reset issues Code TODO suggests Quartz as possible replacement Get rid of REST API calls to self (per optimization) Use of SDK requires git/github (ie. no SDK download) device-sdk repo is an artifact of device-sdk-tools Ideally this should be done via CI Add hooks for security & system management

Device Services MVP Stick with Device Services as released by Dell for MVP RISK: currently device-virtual is the only service released by Dell! Services intended to be released include: BACnet, BLE, Modbus, MQTT, SNMP, and Fischertechnik Apply changes that fall out of Device SDK Tools improvements Hardening + hooks for security & system management Demonstrate native snap-based DS on Ubuntu Core

Device Services MVP BACnet: Uses a 2nd microservice that wraps a Dell Python BACnet protocol library (IP only, no serial support) Eval replacement service based on BACnet stack [C] or BACpypes [Python] Bluetooth Low Energy (BLE): Uses a 2nd microservice that wraps the Python pygatt tool pygatt backends: BGAPI (proprietary) and deprecated bluez tools; limitations with both. Create new OS-specific (eg. bluez on Linux) service(s)

Device Services MVP Fischertechnik: Based on internal Dell Java project Keep as is Modbus Based on Java j2mod library

Device Services MVP MQTT: Based on Eclipse/Java paho MQTT project Demonstrates interoperability with an Android MQTT client Keep as is SNMP: Based on Java snmp4j project

California Release alternative language SDKs based on Barcelona investigation/work Continued improvement to Java SDK and existing Device Services Release any new Device Services Continued work on systems management & security Post presentation discussion: Fischertechnik DS is a serial communications example Device Service Idea of #’s of resources and potential issues still being examined

Core & Supporting Services Jim White

Barcelona Core & Supporting Services MVP Harden the core services (core, metadata, command, config/registry) Harden the supporting services (logging, notifications, scheduler) Harden = works properly for the intended use case (it may not be 100% complete implementations for all use cases or parts of a protocol for example, but it provides enough implementation to sustain the demo use cases for Barcelona and could support extension to the full needs or protocol in the future) handles errors and exceptions gracefully contains proper unit and integration tests follows good coding standards, and is well documented Following some prescribed standard (like Oracle, Google or Twitter guides for Java) performs within the target measures established for Barcelona

Known Core & Supporting Services Issues Core data model changes (per ARM and other concerns) Add hooks for security & system management Perhaps move to California Logging and file based persistent causes OOM exception Device manager – needed? If not then remove Configuration change callbacks in core and supporting services Use of config-watcher Unit/Integration tests for supporting services Performance concerns Footprint (RAM) Start times Latency looks good but need to test/check predictability/consistency

Barcelona or California Core & Supporting Services MVP Go replacement services Config/Registry service changes How complex do we need it? How dynamic? DDS or other message bus into / out of core and supporting services

Miscellaneous MVP Items (not sure whose group?) User interface(s) Demos for Barcellona Post presentation discussion: We need to consider which platforms and OS will be supported for Barcelona (add this to Misc Topics) Intel & Arm; Linux, Windows, etc. We need to consider performance targets in light of something like Kura

Application Working Group Project Scope Draft Janko Isidorovic

Applications WG Northbound (Export Services) Supporting Services Should new services be done in Java only?(we can evaluate using Go Lang) Review/stabilize export layer APIs Define supported MVP export protocols/standards for 1st release Implement Export Services extensions (SDK?) & client registration to meet MVP Add/improve export service docs/examples Evaluate how to handle Application Security and how to plugin to EdgeX Security Module (Sync with EdgeX Security WG). Supporting Services Define Supporting Services Required for MVP. Define Security for Supporting Services (Sync with EdgeX security WG).

Applications WG - To Do List Create Use Cases. Create Test Cases. QA tests of standalone Export Services. E2E test cases. Create List of Cloud Services EdgeX should export data to. Export Services Data Model: Haystack, OPC-UA(more common for south connection to devices). Gap Analysis (Current Project Status vs. MVP). Coding Standards. Define Development Process. Create Development Tasks. Create Timeline.

Applications WG - To Do List - Export Services Current Reference Implementations: Microsoft Azure MQTT Evaluate additional Connectors (Proprietary / Commercial): AWS / Greengrass Google IoT Core SAP HANA IBM Watson IoT Reachout to those companies and ask them to contribute to project.

Applications WG - Projects Project 1: Refine current Microsoft Azure MQTT implementation Implement Microsoft Azure Connector over MQTT. In Boston EdgeX F2F ARM has complained that existing implantation is not production ready. Get more details on the issue. Project 2: Add Security Layer to Export Services Work with Core, Security and Management Work Groups on adding Security to Export Services. Project 3: Evaluate Haystack Evaluate Haystack as data model for exporting EdgeX data. Ideally a Haystack should be implemented as transformation data service that can then be exported through a number of Export Services. Purpose of this project should be to evaluate various approaches. Justin Scott offered to help with this or we can try to enlist someone from the Haystack community.

Applications WG - Projects Project 4: Integration with AWS/Greengrass Create integration with AWS Justin Scott with Building Robotics already offered to do this (at least a general AWS integration). Project 5: Reference EdgeX UI Choose UI Stack (Angular?). Design UI User Flow, Design UI Screens. Project 6: Integrate with Mainflux Server Stack – Will be done by Mainflux Team Create Go Lang based Export/Distribution service that integrates with Mainflux stack on the server side. Potentially use this as the foundation to explore system and device management features. For example the use of LWM2M. Project 7: Push Device Data to Hyperledger Evaluate if there is a need to push device (sensor) data to Hyperledger Blockchain. On meeting in Boston there were few companies who were interested in having this feature. Evaluate if this feature should be scheduled not for MVP but for some later release.

Applications WG - Resources Project Management: PM tools, like Trello, JIRA with Kanban Board and Gantt Charts etc. Developers: Possible Contributors: Justin Scott Jeff Rechten Dave Blohmann QA Resources: Access to EdgeX Reference HW. Access to Microsoft Azure Test Account. AWS / Greengrass Test Account. Google IoT Core Test Account. SAP HANA Test Account. IBM Watson IoT Test Account.

Applications WG - Timeline for MVP Date Action July 15, 2017 R&D - Define Application Work Group Project Scope R&D - Application WG Sub Project Scopes. ??? R&D - Create Development Tasks Implementation - Application WG Sub Projects Done. Testing - Application WG QA Done. Testing - E2E QA Done/Release ready. Release 1 Alpha Release 1 Beta Release 1 GA

Applications WG - EdgeX Scaling - Addressing the “Fog” (2018+) Facilitate East-West capability Scale/Load balance across EdgeX instances Failover between EdgeX host systems Cluster of EdgeX node management Facilitate North-South capability Gateway (EdgeX) Device Service Gateway (EdgeX) to Gateway (EdgeX) export Export/integration with other node types

QA & DevOps Committee Andy Foster 2017 July 13 Conference Call

QA & DevOps Committee At Boston meeting two WGs proposed: QA andTest WG Develop Test Harness/Framework Provide means to measure performance, footprint, etc. DevOps WG Improve EdgeX installation TSC has decided in the short term that these groups should be combined into a QA and DevOps committee that reports to the Core WG

DevOps What is DevOps ? DevOps also automates the process of software integration, testing, deployment, and infrastructure changes It aims to establish a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably DevOps supports an “Agile” software development philosophy

DevOps Issues to be Discussed Development Process How do we adhere more to an Agile process at least within the working groups ? Discuss which development process we should adopt (i.e. Scrum or XP or DSDM etc.) Discuss how we go about implementing and managing the process Product backlog, stories, features – managing each sprint What tools do we need to support the process ? Building and Continuous Integration Review existing build process – from code to Docker containers Review and discuss current code check process and any changes we want to make Branching policy and process needs to be defined Ownership of merge and approvals, etc. Versioning policy needs to be defined Discuss proposal to adopt Sematic Versioning http://semver.org/ Discuss design and implementation of a CI Pipeline (see next slide) Discuss how best to support multiple hardware architectures (Intel/Arm) through build

Continuous Integration (CI) Developers Testers Source Control Server Integration Test Script Functional Test Script Source Code and Unit Test Script CI Server Build Server Code Analysis (Optional) Compile Unit Test (White Box) Private Docker Registry Server Docker Build for Testing Functional Testing Server Execute Functional Test (Black Box) Initialize Test Env. Integration Testing Server Execute Integration Test File Server Copy Artifacts Public Docker Registry Server Docker Build for Production Trigger Return Reports Download Files Other Actions 1 2 3 4 6 5 Continuous Integration (CI) is the process of automating the build and testing of code every time a team member commits changes to version control. CI encourages developers to share their code and unit tests by merging their changes into a shared version control repository after every small task completion. Committing code triggers an automated build system to grab the latest code from the shared repository and to build, test, and validate the full master branch (also known as the trunk or main).

QA Issues to be Discussed QA system/processes Discuss how best to improve and ensure quality Discuss responsibilities around QA how to manage bug tracking/issues/change requests change control policy/processes traceability - requirements to test code reviews formal release checklist and approval Discuss QA tools - e.g. GitHub issues Review and confirm QA resources needs, contributions to deliver the Barcelona release

Testing Issues to be Discussed (1 of 2) Review test categories: unit (white box) - who creates (feature developer ?), owns, inspects, etc. implementation language specific tools to test code base runs without any dependencies (or mock dependencies if required) functional (black box) – docker based micro service test framework that allows for the testing of individual service implementations via their external (EdgeX defined) APIs supports multiple service implementation languages only service and its dependencies should be run when tests are executed integration (black box) – as above, but involves running a complete suite of integration tests all services should be running each time the tests execute other: performance (latency, throughout), footprint, scalability, soak/stability, platform testing, automated code reviews, automated memory leak checking (where appropriate e.g. Valgrind for C/C++)

Testing Issues to be Discussed (2 of 2) Discuss testing methodology e.g. adopt Behavioral Driven Development (BDD) approach to testing Discuss testing tools and frameworks e.g. tools such as Groovy Spock or Cucumber if BDD is adopted Discuss test lab – who, what, where Review and confirm Testing resource needs, contributions to deliver the Barcelona MVP release

Team Structure and Communication Current Chairman: Open (Keith Steele as Core WG chair acting) Email alias: edgex-tsc-qa-test@lists.edgexfoundry.org. Wiki: https://wiki.edgexfoundry.org/pages/viewpage.action?pageId=329484 Discussion forum: #qa-test on https://chat.edgexfoundry.org/ Post presentation discussion: Code coverage is part of the tool / QA process that we want to discuss

July 2017 Presented by Bob Miller of OSU, CASS http://cass.oregonstate.edu/

Who We Are The Center for Applied Systems and Software (CASS) is a unique non-profit experiential learning program in OSU’s School of Electrical Engineering and Computer Science ( http://cass.oregonstate.edu/ ) The Center’s professional staff mentor students to provide software development, testing and hosting solutions for OSU partners and external clients. We are training the next generation of technology leaders. Our partners include organizations like the Linux Foundation, the Apache Software Foundation, the Python Foundation, the Oregon Department of Transportation, the Oregon Department of Education, Puppet Labs, IBM and others.

CASS Areas of Focus Open Source Lab Software Development Group Open Source project hosting DevOps automation and testing Software Development Group Design, development and hosting of new applications Usability testing & early feedback loops Test & IoT Lab Software and Hardware Networking, automation, security, interoperability Internet of Things Protocol release testing for AllJoyn Open Source Project

Available Testing Services Test Plan creation, documentation, implementation & maintenance Major/Minor System Release testing: Running existing regression tests both automated and manual Updating tests as needed when code base changes Documenting/retesting/resolving new defects into project defect tracking system Testing against specific H/W and S/W configurations Participating in release planning & defect triage meetings Test Suite Development & Maintenance Installation / configuration testing: Validate installation scripts, documentation Updating installation / system requirement documentation Hosting/Maintenance of Representative Target Hardware for CI Testing

Allseen Alliance Example AllJoyn Automated Test System Environment Hosting Representative target H/W hosted by OSL VPN server provided Linux Foundation systems secure access to test environment for code updates, and automated testing OSL staff provided any onsite hands on configuration / equipment changes and updates

AllJoyn Open Source Project Example AllJoyn Testing Services Originally 2 major releases and 2 minor releases a year (now primarily in maintenance mode) Major release testing typically lasted 4-6 weeks, minor release testing 2 weeks CASS test team activities: Installation testing on target platforms Ran automated and manual tests Documented / logged defects and validated fixes Participated in Defect triage meetings Updated test documentation Provided updates to Technical Steering Committee

Thank You!

Backup

Test & IoT Lab Testing Technologies Recent tools used in testing engagements: Quality Center/Application Lifecycle Management (HPE tool) Test Link (open source) Jira (for bugs and now test cases using Zephyr plugin) Microsoft Test Manager (via Team Foundation Server)   Recent Testing Environments used: SCONS building from source Git and Gerrit Linux, Windows, Android, iOS, OSX, Open WRT; including building from source on all TravisCI

OSL For more than 14 years, the OSL has provided: Rich, experiential learning opportunities in DevOps and Open Source hosting and development for OSU engineering students Co-location, managed hosting and cloud solutions to promising open source and academic projects Services and test bed capabilities for industry partners working with Open Source technologies. We host more than 150 medium to large FOSS projects including key infrastructure projects like: OCF/AllJoyn IoT test platform hosting POWER8 Open Source Platform Development Python Software Foundation To achieve our mission we are committed to evolving our capabilities to meet the needs of Open Source projects as well as providing cutting edge experience to our student employees preparing them to be future leaders in the tech community Linux Foundation Apache Software Foundation Gentoo Debian

OSL Tool & Technology Evolution OSL is continually renewing the tools and technologies used, in order to provide an environment for our student employees to build expertise on cutting edge DevOps and Open Source software technologies and Best Practices. Our students apply these tools, technologies and best practices to real world projects, mentored by our experienced professional staff and building confidence and expertise.