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

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

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

4. 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)

5. Device Services/ SDK
Tony Espy

6. 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)

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

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

9. 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)

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

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

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

13. Core & Supporting Services
Jim White

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

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

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

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

18. Application Working Group Project Scope Draft
Janko Isidorovic

19. 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).

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

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

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

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

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

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

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

27. QA & DevOps Committee Andy Foster
2017 July 13
Conference Call

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

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

30. 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
Discuss design and implementation of a CI Pipeline (see next slide)
Discuss how best to support multiple hardware architectures (Intel/Arm) through build

31. 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).

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

33. 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++)

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

35. Team Structure and Communication
Current Chairman: Open (Keith Steele as Core WG chair acting)
alias:
Wiki:
Discussion forum: #qa-test on 
Post presentation discussion:
Code coverage is part of the tool / QA process that we want to discuss

36. July 2017 Presented by Bob Miller of OSU, CASS

37. 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 ( )
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.

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

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

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

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

42. Thank You!

43. Backup

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

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

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