Develop Future Proof IoT: Composable Semantics, Security, FuSa, and QoS

IOTG
Future Proof IOT: Composable Semantics &
Quality (Security, FuSa & QoS)
part1: Develop Autonomic Agents
part2: Validate them
Tim Abels
June 3, 2017

IOTG
Agenda – Part1: Develop Future Proof IOT
• IoT = OT control network of machine actionable data ß short term what
• Intro: What is IoT? IoT Maturity Levels? How is IoT Development Different?
• Formal MBSE Dev = OOAD process + SysML language + tool ß long term how
• Model Based Sys Eng (MBSE)
• SysML
• Tool: Commercial and Open Source
• E2E Canonical SysML: Inputs, Ports and Outputs ß long term MBSE hub
• Data Graph Driven replacements (for internet, computers, AI & human contracts) ß
long term what
• What Limits Data (from being the only driver and first class citizen)?
• Part2: validating above, Autonomous Agents
• Call to Action: Data Drives, Formal Develop Data, Data Graph Driven
• More Info: Links, Acronyms
Backup: Tips & labs to quickly learn SysML for IOT. SysML Certification
*Other names and brands may be claimedas the property of others

IOTG
IoT = OT control network of machine actionable data
Controlledsystems of systems (SoS) of sensor and actuators (so Operations
Technology, not IT), connected by Internet (brieflyTCP/IP, DNS)
• Controlled actuation needsFunctional Safety (FuSa¹) and Quality of Service (QoS¹)
• Security¹ adds OT inner network and actuation, to IT surface area.
Data drives driverless,factories,retail,home,etc. IoT Data = all business value, not just
IoT value
• Data: Fused sensor data needs identity, geospatial and time series data to know “which Things
can do what for where and when”. Otherwise digital twin does not map to physical or other
digital twins, and severely limits analyticsand autonomic (self*).
• Metadata: standard annotations for M2M integration, processing, query andreasoning
• Semantic¹ Models: domain-specific(retail, industrial, etc.) and physical-specific (time, space,
geo). Formal ontologies, holistic gluefor meaning analysis and solutions.
1. Our Part1 focus is How to Develop “composable: Semantics, Security, FuSa and QoS” and Part2 How to Validate it.
The term “Quality” will refer to ‘Security, FuSa and QoS (including Fault Tolerance and all 23 ITIL flows)”

IOTG4
IoT Data Control = Stateless SW & HW Layers, exposed for control
1. All control can be remote, including repurposingall SW and all HW that has SW-Semantics (SDN, SD-IOT)
2. IEEE papers: 06059142, 06489684,06890661detail thin & stateless SWApps, API & Management, respectively. PushingHWstate to data layer is identical.
Data middleware handles all Semantics and Quality; with future proof lifecycle, greatlysimplifyingSW& HW.
All control should be in control plane, like Software Defined Network
(SDN)¹ to control & program any resource, any where, any time.
Hyper-scale value with simplicity of one: controller, policy, protocol,
manager, etc.
All data should be in data plane including metadata (transactions,
versioning) and semantics. Otherwise SW² is:
• Inconsistent: siloed app states, checkpoints & versions
• Unreliable: no transaction policy, crash holding locks or state,
heavy state and error handling
• Fat: inefficient, independent of data-layer, vendor entanglements,
and Quality exposure
• Uncontrollable: control (per layer, SW or vendor), no holistic
remote (updates, tuning, fixes)
Apps API Management
Data at rest & in motion
Things
HW
Gateways
HW
Fog
HW
Control Plane
Thin SW layer, no state or embedded control:
Thin HW layer, no state or embedded control:
Data middleware (MS
oData, IEEE)²
Data Plane: all data, metadata, semantics:
Control: centralize all control planes:
**

IOTG5
What are IoT Data (Business) Maturity Levels?
Higher layers & value = increasing formaldevelopment
IoTData=BusinessCurrency
Phase0: Embed device: miniaturization, power efficiency
Data: symbols
infra supplies it,
business owns & uses
Knowledge: answers How
Information: answers Who,
What, When, Where.
Actionable OT, Cyber-Phys
Data x Data: raw IT
Ex: phone
Smart Parking Example
Discover benefits to shops, citizens,
city council…
Why is area not full?
How to tier charges? Find overstaye
vehicles?
Who parks here?
What kind of vehicle?
When are peak periods?
Where is empty?
Connect all empty,full & history
Empty or Full (0 or 1)
Wisdom: values Why
What is the right investment level for your IOT projects? Phase 2, 3 (or prep for 4)?
IoT/Biz Value is data owners. Their machine actionable data. Smart Parking example above.
Explains: answers new
questions & context

IOTG
How is IoT Development Different?
Traditional Development (IT, Web) IoT Development¹
Guiding Developer
Principle
Informal art, can’t double requirements annually
or ensure error can never happen again
Engineering, formal math for complete, correct &
future proof. Sufficient for driverless everything.
Internet, systems
of systems
IETF.org API syntax-only, version-
specific integrations
Std ontology & metadata: to learn, discover
Semantic composition. Briefly TCP/IP & DNS
Things 3x9’s is best uptime² (51 min/year outage) QoS and 9 x 9’s uptime
Security and
Safety Risks
Secure digital surface area. No physical
security or safety.
FuSa and Regulatory Compliance, secure
control network and actuators
Contracts & payment Human contracts M2M Smart Contracts & Payments
Browsers Human-only, read-only, mostly MIME
(text, audio, video)
Autonomic Agents (M2M browser for data &
control), stateless and controllable SW & HW
Security Broker DNS, Certificate Authority, Remote AAA Contract Broker for agents
Development
(Part1). This PPT
Paper requirements. Disjoint artifacts & tools
with much manual maintenance
One model for entire lifecycle, all views, all reports,
code and tests (auto-generated)
Validated (Part2)
Next Slide
Some version-specific SW & HW state API’s
validated. No formal/math guarantees
Formally complete & correct. Adapts to 100x faster
Adversary Deity (with full knowledge of weaknesses)
1. Right column is future proof, when Data becomes the only first class citizen, & random tight-coupling (non-Data) is removed (including later TCP/IP, DNS… )
2. UptimeInstitute.org datacenter highest L4, is all active-active failover, but pre-IOT shared their data (in memory, C/C++ pointers, TCP/IP, etc.), so data dependencies were
spaghetti, not data graph driven (DGD)

IOTG
MBSE Motivation: Traditional Fault introduction, discovery and estimated removal cost for IT:
5x
Software
Architectural
Design
System
Design
Component
Software
Design
Code
Development
Unit
Test
System
Test
Integration
Test
Acceptance
Test
Requirements
Engineering
30x
Source: NIST Planning report 02-3, “The Economic Impacts of Inadequate Infrastructure for Software Testing
20.5%
1x
20%, 16%
10%, 50.5%
0%, 9% 15x
70%, 3.5%
10x
MBSE finds faults in the requirements-architecture design phase (left side).
Continually doubles requirements & can’t reintroduce fixed problems.
This 3.5% is “The Problem” of IOT Dev.
Goal of 80% and continually increase.
Only partner with MBSEdepartments &
companies.
Expensive to find or remove
Faults late (in red)
And introduces more Faults (in blue)
Expect IOT to increase these (costs and late fault
introductions) by 100x, since: regulatory, mission
critical, & dynamic twin of changing physical
It’s Cheap to avoid, find and remove Faults early (MBSE!)

IOTG
Agenda
• IoT = OT control network of machine actionable data ß short term what
• Intro: What is IoT? IoT Maturity Levels? How is IoT Development Different?
• Formal MBSE Dev = OOAD process + SysML language + tool ß long term how
• Model Based Sys Eng (MBSE)
• SysML
• Tool: Commercial and Open Source
• E2E Canonical SysML: Inputs, Ports and Outputs ß long term MBSE hub
• Data Graph Driven replacements (for internet, computers, AI & human contracts) ß
long term what
• What Limits Data (from being the only driver and first class citizen)?
• Part2 Teaser: validating above, Autonomous Agents
• Call to Action: Data Drives, Formal Develop Data, Data Graph Driven
• More Info: Links
Backup: Tips & labs to quickly learn SysML for IOT. SysML Certification

IOTG
One Formal SOR Model assures Everything & generates Every View
9
One (source) mountain, (generated target) pictures are incomplete views & quickly outdated.
• What source: One model: bill of materials(BOM), blocksand flows hierarchy,
• How process: Formal:mathematically complete and correct,continually scales,can’t reintroduce fixed errors.Ex: 50 stacked
Amish barnsis an art, not engineeringlike skyscrapers, which can continuallydouble requirements(twice the skyscraperheight,
quantity,wind,weight,etc.)
• How authority: One SOR: authoritative SystemofRecord
• What target: Everything: generates all other SOR, requirements (DOORS*), API, unit tests, executive & assurance reports, regulatory
compliance, etc.
• Who, When, where: Every View:generatesall subsets/versionsperrole/view: time/schedule,space/geo,product compliance/SKU,
etc.
Diagram Source: csse.usc.edu
RTF (Word) & HTML

IOTG
Formal MBSE Dev = 1 process (OOAD) + 1 language (SysML)+ 1 tool
10
MBSE: Model Based Software Engineering, so a single system model generates 100% of reports, status &
compliance. It exports/drives secondary/derived systems of record (SOR), avoiding 10 SOR (outdated and
disjoint with error-prone manual resynchs). Initial goal of 80% inputs to a SOR, and add more % and more
SOR, including SOR Tools for: Requirements (DOORS*), Use Cases, Exec and Assurance Reports, etc.
Software Engineering: continually scale via formal language (complete, correct), automates INCOSE,
which defined Software Eng.
OOAD¹: Object Oriented Analysis Design process
SysML: Earliest realization of 99% Use Cases, Requirements & KPI, including namespaces for specific
Standards, Regulatory, etc. Generate all initial: Test Cases, Interfaces (HW & SW), schedules, documents,
etc. Cleanly separate what’s formally generated from informal (pre-IOT, with no Quality guarantees).
Tool: SysML v1.4, ports, export, XMI compatible to open source (ex: ModelIO),
1. OOAD is a useful subset of Aspect Oriented Design (AOD), but only static compile time and only 3 connection types
between classes (polymorphism, inheritance, encapsulation). SysML Ports = AOD runtime connection types (Part2)

IOTG
Canonical E2E Formal Development
SysML v1.4: 3 Blocks + 4 Flow
diagrams. Attach Req & KPI
diagrams, connected by ports.
PerVertical&Role
Input: Requirements, KPI, Layers
Control, smart contracts
FuSa, security, regulatory…
Standards, roles/views, …
Versioned Hierarchy of
SysML Blocks& Flows
Output: Assurances &Auto-Generate
Requirements, KPI
Layers:
Data/Metadata
Semantics
Network
Platform
…
1
2
4
3
5
6 Reports: Executive, Status, est. Schedule
Compliance/Regulator/FuSa
Checkpoints (M2M Contracts, payments)
Unit & System Test suites
Software interfaces (C/C++, Java, JS)
Hardware interfaces (SIMICS*, FPGA)
PerVertical&Role
9
10
2 Lab & 2 Product Environments7
8
11
Start with Quality. Keep it with future proof extensions & composable.
See details and Guided Tours of steps 1-11 in slide notes.
Assurances:
Auto-generate initial:
Ports: complete & correct
Port conflicts on check-in breakthe build, and must follow those role’s
resolution policy fortheir regulatory, securityor FuSa. Ex: ensure512b
ECC encryption for aerospace E2E.
Reports are always current. Ex: % compliant, conflict, not started.

IOTG
Model Based Systems Engineering (MBSE) – Manual vs Auto
Manual Doc-Based MBSE (Model-Based Systems Engineering)
•Informal, error-prone, paper.
•Isolated from formalism, languages and tools.
•Formal models of objects. Integrated, coherent and
consistent using a dedicated systems modeling tool.
Can’t re-introduce fixed error.
• XMI interchange XML with other tools: SysML, UML, BPEL..
•Disjoint artifacts and tools: Use Cases,
Requirements, API, Traceability, Test Cases,
System Constraints, etc.
•Unclear roles, views, versions, decision log, etc.
One tool and model. “One Mountain, many pictures
(views)”
Central repository for earliest design decisions. Then as-
needed reports and views for these.
•Significant maintenance of artifacts (cost, time
and lost opportunities), otherwise obsolete.
•Manual, so inconsistent and error prone. Which
artifacts were impacted and where? What are
their dependencies?
Automated cross-diagram and inheritance, extend only
the min needed (continually scales), change one time to
one block with dependencies instantly propagated.
No language, so no completeness, correctness or
annually doubling requirements
Generate interfaces for major SW code (C/C++, Java, JS)
and HW simulators (VHDL, SystemC) from SysML Language
Formal MBSE Dev = OOAD process + SysML language + tool (ex: SparxSystems* Ent Arch v13)
Part1: Dev best practices. Part2: Validation best practices.

IOTG
Why Model Based SE Process & SysML Language?
Based on Dev cost insights & XLS from Dr. Barry Boehm of csse.usc.edu
Tip: can design SysMLsprints in an Agile scrum style, but check into SysMLevery week (here week = unit of informal risk/throwaway)
Time
$
Over-engineered (unless
mission-critical justifies)
MBSE. Ex: SysML (7 Diagrams, Requirements & Constraints) is:
1. developer cost sweet spot
2. continues to scale
UML 30 Diagrams. INCOSE paper process (without SysML tool)
Disjoint, major tools: requirements, test cases, API, etc.
Under-engineered for: versions,
remote updates,
semantics, future proof & learning
Quick Method
(Ex: Agile without
full verification
before checking
into build)
Informal: lacks
FuSa, Security
Regulated method (ex: NASA)
Informal tools
Code without Diagrams
1
2
3

IOTG
SysML (not UML) for IOT
1. Clean, orthogonal subset of UML
2. Adds Requirements & Parametric
KPI (per block & flow)
3. Chains sub-block and flow with ports
4. Adds HW by extending UML DataType
with ValueType (power, flows, physical)
5. Aligns to IOT Things, including OCF
CDM, UPnP formats
6. Aligns to IOT Standards (SysML at
OCF, IIC, OMG, etc. conferences)
Other MBSE Languages are not systems or
as applicable to IOT
SysML 7 Diagrams (4 unchanged, 3 changed from UML 2)
Add Requirements and Parametrics (KPI Constraints) to any sub-block or flow, chain
them via ports for complete & correct, their reports, regulatory, etc.
Activity
Diagram
Use Case
Diagram
Internal
Block
Diagram
Block
Definition
Diagram
Behavior
Diagram
SysML
Diagram
Structure
Diagram
Same as UML 2
Modifies UML 2
New diagram type
Sequence
Diagram
State Machine
Diagram
Package
Diagram
Parametric
Diagram
Requirement
Diagram
triangle “is-a”,
diamond “has-a”
Arrow “link relation” (active verb) to arrow head

IOTG
Evolution of UML and SysML Standards
www.incose.org/ProductsPublications/sehandbook 4th edition of International Council on Systems Eng (INCOSE), the foundation of System
Engineering
Diagram source: csse.usc.edu

IOTG16
SysML Tools
Commercial Grade
Must have: SysML v1.4, ports, export, XMI compatible to open source (ex: ModelIO)
• Enterprise Architect*, by SparxSystems.com ß used in these presentations
• Cameo Systems Modeler* by No Magic
• Others: Agilian*, Artisan Studio*, IBM Rational Rhapsody*, Altova Umodel*
• Avoid diagramming Tools (Visio*, SmartDraw*, etc.), no underlying language & model
Free, Open Source
• Modelio* by ModelioSoft, can import/export via XMI, to others like EA above
• Payrus* by Atos Origin, not recommended for UML or SysML
Tips: use commercial tool for max productivity, but ensures export XMI of the major artifact NDA versions to Modelio for
partners. Can export HTML and reports when read access is sufficient.
Annual renewal is typically 30% of one-time. Floating Licenses are only 10% more. 10 Floating is sufficient for 100 senior devs.

IOTG
Canonical E2E Formal Development
SysML v1.4: 3 Blocks + 4 Flow
diagrams. Attach Req & KPI
diagrams, connected by ports.
PerVertical&Role
Input: Requirements, KPI, Layers
Control, smart contracts
FuSa, security, regulatory…
Standards, roles/views, …
Versioned Hierarchy of
SysML Blocks& Flows
Output: Assurances &Auto-Generate
Requirements, KPI
Layers:
Data/Metadata
Semantics
Network
Platform
…
1
2
4
3
5
6 Reports: Executive, Status, est. Schedule
Compliance/Regulator/FuSa
Checkpoints (M2M Contracts, payments)
Unit & System Test suites
Software interfaces (C/C++, Java, JS)
Hardware interfaces (SIMICS, FPGA)
PerVertical&Role
9
10
2 Lab & 2 Product Environments7
8
11
Start with Quality. Keep it with future proof extensions & composable.
See details and Guided Tours of steps 1-11 in slide notes.
Assurances:
Auto-generate initial:
Ports: complete & correct
Port conflicts on check-in breakthe build, and must follow those role’s
resolution policy fortheir regulatory, securityor FuSa. Ex: ensure
512b ECC encryption foraerospaceE2E.
Reports are always current. Ex: % compliant, conflict, not started.

IOTG19
Semantic Taxonomy: Expressiveness X Application Interop
Benefits of binding OWL-DL & Smart Contracts
with DDS:
1. Integrates the most extreme ends,
disintermediating many syntax and semantic
layers
2. Combines OWL-DL, the most secure Semantic
DL (based on DARPA Agent) & Data (DDS for
aerospace, medical, military, etc.)
3. E2E Data: DDS cross-platform using IDL
4. Bind OWL-DL & DDS checkpoints to Smart
Contracts terms and payments
5. Extend with composable: semantics, security,
QoS, reliability, FuSa, etc.
SemanticExpressivenessweakstrong
data interoperability
platform interoperability
structural interoperability
semantic interoperability
RDF, RDFS
SysML
UML
OWL, DAML
Description Logic
OWL-DL,
First Order, Modal Logics
Logic Theory
Concept Theory
ER, Extended ER
XML, DB Schema
XML, Relational
Models
DataRecords
IDL
DDS
Taxonomy Theory
Application Interoperability
syntactic interoperability
Smart
Contracts
Logs Device Trust

IOTG20
E2E Outputs: Assurances and Auto-Generated
Assurances
• Reports: executive, status, schedules
• Compliance: geo, regulatory, FuSa, QoS, security, etc.
• Checkpoints: data actions and transactions, M2M contracts and payments
Auto-Generated
• Unit & System Test suites
• Software interfaces: C/C++, Java, Javascript
• Hardware interfaces: SystemC and VHDL for SIMICS* and quick POC (FPGA)

IOTG
MBSE outputs Assurances
Assurance = Quantitative confidence and validation tests in Quality
claims as System Architecture continually changes
An assurance case is:
§ a documented body of evidence (SysML Report: exec, regulatory, schedule, etc.)
§ that provides a convincing and valid argument
§ showing that an artifact (named, port-connected SysML blocks and flows)
§ has desired properties (composable Quality: security, FuSa, QoS, etc.)
§ i.e., a documented chain of reasoning that supports some claim (driven by requirements or
parametric KPI, later: data graphs)
§ How: based on SysML ports evidence, calibrated and validated in software (ex: SIMICS* functional
simulator) and implementation (ex: FPGA)

IOTG
Where do I start? Handoff? Duplicate testbed or lab? Communicate
bugs? Automate & Scale?
How many disjoint tools & environments needed?
What’s status?
Model entire IOT System for entire Lifecycle
• Co-Design from years before Silicon through product end. Hardware, Software Devs, Integrators,
Testers & SysAdmin use same platform for board bring up, step debugging & IOT Management.
• Instruction Set Simulator for full BIOS, OS, and App binaries. Run unmodified software and
python scripts on production Things, Gateways, Fog, etc.
• Formal: Underlying virtual platform continually scales, reuse for derivations and customizations.
Sssertions ensure correct, complete and manufactureable.
Why Simulation for IOT Devs and Integrators?
MBSE + SIM Automation Goal: double productivity per year

IOTG
Functional Simulator - Build Models & Run Unmodified Software on workstations or
clusters, at any IOT Level of 100s of Things: Site, Factory, datacenter, etc.
SDAW E2E

IOTG25
What Limits Data (from being the only First Class Citizen)?
Random, historical tight coupling:
• Routing tied to TCP/IP. Naming to IP/DNS. Certificates to files/blobs.
• Quality boundaries (security, FuSa, QoS) like Fault Tolerance are tied to SW or HW; their
vendors, history and versions. Thus, uptime over 3x9’s is rare outside Erlang Open Telecom
Platform (OTP).
• Execution tied to CPU Core, instead of minimum data movement (for optimal power, latency
and surface area/Boundaries for Quality).
• AI Wave2: fragile learnings; tied to sample data, uniform algorithms and HW
• Contracts and payments tied to humans (informal). Causes misunderstandings and litigations.
Not instant, actionable, semantic or composable.
Identify and replace the legacy limitations, like above when:
data driven (factories, retail, etc.) can’t continually double requirements.

IOTG26
Data-Graph-Driven (DGD) (1 of 2)
Replaces legacy: uptime, Internet, computers andArtificial Intelligence.
DGD Disruption Semantic Benefits Leading Examples
Replace
boundaries,
dependencies
with DGD
The perfect isolation level for quality (fault tolerance,
security, FuSa, etc.) is DGD of processes. Unlike current data
centers max of 3x9’s (per uptimeinstitute.org Level4 all
active-active) so any shared memory, compute, language
(C/C++, Java), etc. best is 51 minutes outage/year (9x9’s)
9 x 9’s uptime in Erlang Open Telecom
Platform (OTP). Supervisor processes
bound min dependent group, and restart
in sub-second
Replace TCP/IP
with Named
Data Networks
(NDN)
Data becomes the first class citizen (earliest package it,
name it, own, control, manage, secure, FuSa, etc.). Includes
NDN for data-like (metadata, semantics, keys, etc.). Avoids
tight-coupling meaningless TCP/IP and fixed paths, with
exposed hosts and hops of faults, insecure surface areas and
E2E networks, etc.
Search IEEE & IETF for NDN by Dr Lixia
Zhang, replacing TCP/IP, DNS, x509
Certificate Authorities, etc.
Replace Von
Neumann¹ with
DGD
Data movement limits all latency and power, and expands
surface area of Quality risks. Moore’s Law generations
reduced space from entire die, to multi-core, to hetero systems
arch (HSA), to bringing the compute & memory to the data.
DGD overlays on guaranteed min areas of
micro execution units (uEU) and similarly
for memory.
AI Wave 3 Wave2 ML/DL scales with big data, but is fragile. Wave3
adds abstract learning, and adapts to new: context &
missions/tasks.
Early, domain-specific results on data-driven
neurons on non-VonNeuman HW &
memory above
Remove all legacy tight coupling that limits data’s citizenship & freedom.
Only machine actionable data drives everything.
1. Current computers are based on VonNeumann architecture. Fetch & execute cycles repeatedlybring the data to the compute & memory.

IOTG27
Data-Graph-Driven (DGD) (2 of 2)
Replaces legacy: Internet DNS/Naming, data/packet network, Human Contracts,etc.
DGD Disruption Semantic Benefits Leading Examples
DNS/Naming Naming provides IOT group boot time, much like
DNS is before all Internet v1 protocols and can exchange
data to coordinate a group, it’s not just a naming service
See IETF NDN-based DNSSec and DANE,
with Dr Lixia Zhang, etc.
Data packets &
throughput
Data packets are first class on COTS platforms, so no
blocking, synchronous, interrupts, copies or ring transfers.
DPDK.org API used by all major switch and
IOT Gateway vendors. Continual
community improvements
Smart Contracts Rule of law on machine actionable data, with formally
complete and correct DGD. Digital twins of physical world &
contracts
Autonomic Agents (M2M browsers) of
contract controlled data
XX

IOTG
Data Dependency Graph. Ex: Erlang* Open Telcom Platform (OTP)
Ideal isolation level for Semantics and Quality
28
Processes linked for data dependencies!
1. if worker3 faults and worker4 has
dependent link (and cascading any worker
processes with dependency links to
worker3), then
2. supervisor2 kills entire group with
dependencies and restarts them for
isolating the fault domain (worker3 and
worker4 here).
Processes monitored by supervisors
• Light processes spawned, migrated, copied
quickly
supervisor2
worker3 worker4
worker1 worker2
Supervisor
1
namespace12

IOTG29
Why does IOT need DGD Fault Tolerant 9 x 9’s
Below problems impact Fault Tolerance and are fundamental to non-isolated: C/C++, java, OO,
threads, locking, memory, etc.
1. Uptime: Quality datacenter is 99.9% or 51 minutes/year outages. Why not sub-second per
year?
2. Errors: Quality code is 300 lines/error. Unknown dependencies in other SW or nodes
3. No Transparency: recode app for each context, network, infra, referential transparency, etc.
4. Scale: processes too heavy for millions per node, or to migrate, copy or restart
5. Concurrency: provided by locking so starvation, crashes hold locks, hard to debug
6. Imperative: low level steps, instead of declarative
7. Microservices: should be equal or subset of a process (unit of execution, isolation,
concurrency, restart)
8. Updates: dual and conflicting types, half of upgrade is on an old version (half of computer,
datacenter, network, etc.)
9. Try-Catch: unknown states,
10.Debug: non-repeatable, race conditions, locking, etc.

IOTG
Named Data Networking
Diagram source: https://en.wikipedia.org/wiki/Named_data_networking
IP-Based Approaches Named Data Networking
Earliest capture of data. Package it, name it, own and control it, publish andsubscribe it.
Everything built around the named data, replacingTCP/IP, DNS, etc.

IOTG31
CPU Microarchitecture Generations
Moore’s law = density (distance for speed of light)
Data movement limits latency, power and surface area/boundary for security and Quality.
1. Entire Die: data movement was across entire die
2. Multi-core. Ex: reduces 1 die to 10x10 cores for upto 100x data movement area per core of
entire die (.1 x .1) and 100x parallelism.
3. Hetero System Arch (HSA): reduces big cores, to mix of small, tiny, TPU cores, for 100x data
movement and 100x parallelism of Xeon or Atom cores.
4. Data Graph Driven (DGD): ensure minimum data movement on minimal transistors. Prior
generations used Von Neumann computers (cycles of fetch data and execute on compute) and
traditional compilers. DGD generations brings the compute to the data, and requires new data-
graph compilers to map to very tiny neighborhoods of minimal transistors.

IOTG32
Analytics Tools and their Result – per 3 AI Waves
Analytics Tool Result 3 AI Waves
Classification What is the problem? 1. Descriptive(ex: Movidius, Saffron, Watson)-
builds cross relationships dictionary for rule-based
reasoning to perceive
Scope: existing as-is model, but narrow domains
and no learning
Data clustering Where, when, how many, how often?
Detection What happened?
Modeling What could happen? 2a. Predictive(ex: Nervana)- builds statistical
models to predict next events.
Scope: builds should-be model, scaled with
training, but narrow concrete-only learning, fragile
with new context
Anomaly Detection Are actions needed?
Predictive Modeling What will happen next?
Forecasting What if these trends continue?
Optimization How can we obtain the optimum results? 2b. Prescriptive(ex: Nervana) - same as
Predictive, but adds statistical optimizations for
best gaps, results or trends
Scope: same as Predictive
Stochastic
optimizations
How obtain optimum results,
including uncertainty effects?
Contextual adaption Explain classes of real world phenomena. 3. Explain - builds explanatory models of classes
of real world phenomena)
Scope: open, learns and reasons on new situationsAbstract learning Learn and reason on new tasks
and context
Wave3 : www.nextbigfuture.com/2017/02/darpa-sees-future-third-wave-of.html includes videoand details
Wave 3 (Explain, yellow above), is early & several Nobel Prizes from realizing human’s adaptive Intelligence.

IOTG33
DPDK.org, source code on github. Packet acceleration in user space
Note: 17.05 means 2017 May release (Ubuntu numbering scheme YY.MM)

IOTG34
DPDK.org – First class Data Packets
No interrupts, blocking, copies, ring transfers (from Ring3 to Ring0) since DMA, etc.
Used by all major switches, IOT gateways, etc. for 2-50x throughput on COTS

IOTG
One Source Architecture Model
Multi-Dimensional Analyses from same model discovers faults early.
Annotations include Requirements & parametric KPI.
Latency analysis
Schedulability analysis
FuSa analysis
Reliability analysisFault
annotations
Timing
annotations
SysML Ports
SW/HW
SysML Model
Low incremental cost for additional validation analyses & simulations.
Separate non-functional annotations by dimension: space, time, identity, etc.
Data Behaviors
& Structures
Geospatial
annotations
Location analysis
Speed analysis
Environment
annotations
Temp analysis
Humidity analysis

IOTG37
Aspect Oriented Design (AOD)
AOD = any data property,anywhere, anytime.The sufficient superset of OOAD
SysML Ports = AOD connection types
SysML Port assurances (of requirements and parametric KPI) are the ideal recommenders
of AOD connection types (relations between classes and runtime instances), including
geospatial, timing, regulatory quality, etc.
Object Oriented Analysis Design Aspect Oriented Design¹
Data Binding times Static compile time only Any dynamic time
Data relations 3 relations between classes (PIE):
polymorphism, inheritance,encapsulation
Any relation. Static classes and
runtime instances
Data Scope Parent-child hierarchies Any data scope, any where
1. Functional Programming has similar flexibility tocontinuallybuildanddouble functionality, but is based onfunctions,
unlike AOD: data graphdriven(DGD) withdataas the first class citizen.

IOTG
Model-based Validation
Predictive analysis, based on data & semantics, across views
Security
Confidentiality
Integrity
Accountin
Availability
& Reliability
MTBF
Regulated uptime
Fault analysis
Real-time
Performance
Execution time/
Deadline
Deadlock/starvation
Latency
Resource Consumption
Bandwidth
CPU time
Power Consumption
Data precision/
accuracy
Temporal
correctness
Trust/Confidence
Data
Quality
One Architecture Model
One Source Model reduces validation cost, increases validation test automation

IOTG
Command & Control (C2) Managed
Cloud Analytics
Networks
Autonomic C2Agents (self* adapt &
intelligent)
Platforms
Validation
(SysML, fSIM, FPGA)
Formal Dev & Validation
Security
learnings
services
capabilities
& alerts
Red Deity
Models
God-mode
Red Deity
God-mode
Specific missions,services & capabilityrequirements
Autonomic Agents – Validation ContextArchitecture
Debug the gaps between God Mode and validated Quality& actual learnings
Red Deity (adversary) stress tests Agent’s Autonomicwith 1000x more resourced and
adaptable, and has access to God Mode with all Agent weaknesses and tradeoffs
Low incremental cost for extreme validation analyses & simulations!

IOTG41
Call to Action
• Identify initial SysML project. Solicit SysML mentors to assist, self-teaching groups.
• Measure Architects and Devs performance on: scalable, auto-generated, formally complete
and correct. I.e. what doesn’t get thrown away now or later.
• Build SysML models soon for broad IOT Platform, and derive per vertical
• Auto-generate all other Systems of Record (SOR): DOORS Requirements, etc.
• Generate namespace wrappers specific to standards, regulatory, product SKUs, etc.

IOTG42
More Info (1 of 2)
MBSE (INCOSE SE Handbook)
• www.incose.org/ProductsPublications/sehandbook current: 4th edit July 2015
• www.amazon.com/INCOSE-Systems-Engineering-Handbook-Activities/dp/1118999401
• www.amazon.com/Writing-Effective-Cases-Alistair-Cockburn/dp/0201702258/ Use Cases
SysML
• www.omg.org/spec/SysML/ current: v1.4 build 1228, Feb 22 2016
• www.amazon.com/Practical-Guide-SysML-Third-Modeling/dp/0128002026/ best book
• www.jhuapl.edu/ott/Technologies/Copyright/agreementStatement.asp?documentName=CourseMaterial_Co
nceptsOnly.zip 500 slides for book, adds EA Tool, IOT and Process
• www.sparxsystems.com/resources/booklets/ebook_list.html#embed-sysml Free IOT eBook with MBSE
process, Ent Arch, and SysML generates C/Java/JS (ch.7) and VHDL/Verilog (ch.6)
SparkSystems Enterprise Architect v13 Systems Engineer edition (with SysML)
• www.sparxsystems.com/resources/webinar/webinar-series.html
• www.sparxsystems.com/products/ current: EA v13 with SysML 1.4
• www.sparxsystems.com/products/ea/compare-editions.html get Sys Eng editition, Float License

IOTG43
More Info (2 of 2)
Video Tutorials
• www.youtube.com/user/SparxSystems Sparx Systems (ensure SysML diagram)
• www.youtube.com/watch?v=DcnO73QNGSQ open source Modelio
ModelIO Open Source SysML: XMI import/export XML between Tools (some incompatibilities)
• www.modelio.org/tutorials/how-to-create-sysml-diagrams-in-modelio.html
• http://sysml.tools/review-modelio/
Systems Engineering
• www.incose.org/ProductsPublications/sehandbook - current: 4th edit July 2015
www.amazon.com/INCOSE-Systems-Engineering-Handbook-Activities/dp/1118999401
• http://csse.usc.edu Center for Software & System Engineering, with dev cost insights

IOTG
Acronyms
44
5G: 5th Generation Telephony
ACT: Activity Diagrams (SysML)
AOD: Aspect Oriented Design (vs OO)
CDM: Common Data Model (OCF.org)
COTS: Common Off The Shelf (HW)
COW: Copy On Write
DDS: Data Distribution Service (OMG.org)
DGD: Data Graph Driven
DL: Deep Learning (DL)
DNS: Distributed Name Service (Internet)
DPDK: Data Plane Dev Kit (.org)
E2E: End-to-end
EA: Enterprise Architect (SysML Tool)
fSIM: Functional Simulator
FuSa: Functional Safety
HSA: Hetero Systems Architecture
IIC: Industrial IOT Consortium
INCOSE: International Council on SE
IOT: Internet of Things
IP: Internet Protocol
IT: Information Technology (vs OT)
ITIL: IT Information Library
JS: Javascript
KPI: Key Performance Indicators
M2M: Machine-to-machine
MBSE: Model Based SE
ML: Machine Learning (AI)
MVC: Model View Controller (pattern)
NDN: Named Data Networking (vs TCP/IP)
OCF: Open Connectivity Framework
OCSMP: OMG Certified Systems Modeling Pro
OMG: Open Management Group (.org)
OO: Object Oriented
OOAD: Object Oriented Analysis & Design
OT: Operational Technology (vs IT)
OTP: Open Telecom Platform
OWL: Web Ontology Language (W3C.org)
OWL-DL: OWL Descriptor Language
POC: Proof of Concept
QoS: Quality of Service
SD: Sequence Diagrams (SysML)
SDN: Software Defined Network
SOR: System of Record
SE: Systems Engineering
SoS: System of Systems
STM: State Transition Machine Diagrams (SysML)
SysML: Systems Modeling Language (vs UML)
UC: Use Case Diagrams (SysML)
UPnP: Universal Plug and Play
UML: Unified Modeling Language (vs SysML)
XML: XML Interchange
XML: eXtensible Markup Language

Thank you !
Q & A
Backup slides: Learning SysML for IOT

IOTG
Learning SysML
• When: Self learn on a current project needing designed, with several half days available.
• Who: Groups of 2 or more, with mentor available for questions and initial.
• What Prep: Multiple large monitors.PrintedReference Card. A Practical Guide to
SysML book (and download .ZIP of trainingthat uses it). Pre-InstalledSysML
Tool, example: Enterprise Architect*,Systems Edition v13 or ModelIO*
• What Dev: Five labs that each generate a useful report of SysML diagrams.
1. Generate Glossary from Domain Model.
2. Generate early Requirements Report & HTML for customer feedback.
3. Generate early, coherent Report (behavior and structure) & HTMLfor feedback.
4. Generate full, versioned Report & HTML.
5. Generate Code & Test Cases
• How: combination of .ZIP examples and hands-on IOT-specific, with EA steps.

IOTG47
Installing Enterprise Architect v13 (1 of 2)
Trial Version of SparxSystems.com Engineer Edition (with SysML)
1. Select Link – Please use Chrome www.sparxsystems.com/products/ea/trial.html
2. Once you get the email, open the download link in Chrome,
open the msi file and run. Windows may ask you to accept
the file from an unknown source. Install as specified below.
Be sure to select the “System Engineering” option.
3. Select agreement and then select next
through the installation:
4. Search for EA on your desktop or start menu and run

IOTG48
Installing Enterprise Architect (2 of 2)
5a. If you get this box
Following this link to request a 30 day extension key
www.sparxsystems.eu/resources/license-management/trial-installation/
To enter an extension key, A. hold [Ctrl] on the keyboard, B. enter the key
including braces Ex: {…} and C. click the "Continue Trial" button on the dialog.
6. When you get this screen
Select Systems Engineering, then OK
Since SE version is needed for SysML.

IOTG49
2.
1.
3.
RSVP 4 Labs Ex:
Source: Chapter 4 ofPractial Guideof SysML
(Variable)

IOTG50
Lab1 of 5: Domain Model Tips – becomes your project glossary
1. Focus on the real world objects and their relationships (for your problem domain)
2. Relate objects with generalization (is-a triangle) and aggregation (has-a diamond)
3. Do domain model before UC and Req. Creates a glossary to avoid name ambiguity
4. Keep this top level clean. Don’t add GUI (classes, screens) or non-functional (Quality,
*abilities, etc.)
5. Quickly get to 80% complete before moving on to UC and Req diagrams. Can iterate later
6. OOAD Design tips for Domain Model Blocks (Classes):
§ Loose coupling with other blocks
§ Internally cohesive and complete
§ Get 80% sufficient base operations for now (iterate later for alternate and rare)

IOTG
What are Use Cases?
• Describes a sequence of events that represents a User’s interaction with the system to
perform a specific task (basic path, alternative/exceptions paths)
• A bridge between Usage Models and Requirements
• Common language between R&D, Strategic Planning, Architecture, Development and
Validation
• Ultimately they manifest themselves by end Users
Create Basic Path, Alternate Path, and Exception Path for each Use Case. Have diverse teams
review each Use Case in a group setting, for additional dynamic discovery and cross-training.
• Catches many mistakes and Alternate Paths or Exception Paths that individual skills miss.
• Identifies open architectural issues early
• Note Basic Path data and flows used in multiple Use Cases and split them out into
separate data and Use Cases that M2M data could “invoke” (i.e. a function)

IOTG52
Lab2a: Use Cases Tips
1. Story boards identify use cases. Actor: external to system; Acts (Active, clarifying verb).
System: internal; Responds to Actors.
2. Author UC in the context of the Domain Model glossary. EA Tool supports names, linkage and
traceability (between domain name, use cases and requirements). Drag and drop to ensure
linkage
3. Separate scenarios (path through UC) into base (sunny day) and alternate (rainy day), doing
rainy day after 80% UC
4. Only separate out includes (common) and extends, after 80% UC
5. Name MVC (Model View Controller) Objects. Put boundaries as Views, responses as
Controllers and Entities as Models)
6. Print report of Domain and UC, add GUI/POC mockups for review with end users
7. Later: UC will determine packages (EA projects of diagrams for views and reports)
* For soliciting effective UC from users and PoC, see www.amazon.com/Writing-Effective-Cases-Alistair-Cockburn/dp/0201702258/

IOTG53
Lab2b: Requirements Tips
1. EA Tool supports names, linkage and traceability (between domain name, use cases
and requirements). Drag and drop to ensure linkage.
2. Use Active Verbs
3. Distinguish functional requirements from non-functional (infra Quality, *abilities)
4. Distinguish types of requirements (categories per view, report, test case)
5. Later: one or more test cases linked to each requirement

IOTG54
Lab3a. Sequence Diagrams (SD) Tips (1 of 2)
When to use SD:
• SD,ACT and STM are suitable for dynamic coordination across Model View Controller (MVC)
classes
• SD is suitable for coordinating control across MVC classes (for I/O coordination use ACT, for
transitions between discreet machine states use STM)
• For every suitable UC do a SD, with basic and alternate courses on the same SD.
How to use SD after UC analysis (MVC):
• Start your SD left to right adding one UC’s coordinated: Actors, then View classes, then Controllers,
and finally Models
• Use the SD to coordinate UC Controller functions across the MVC classes (top row).
• Add UC text that result from MVC. Ensure text maps to the messages being passed on the SD. Move
text to line up under it’s class (EA defaults leftmost)
• While drawing messages, assign every operation to a class. Review your Domain Model frequently, to
make sure all these operations are on their appropriate classes.
Review:
• Sufficiently analyze your design’s coordination on SD before coding.
• Clean up the static model before proceeding to Lab3: Early Design Review.

IOTG55
Lab3a. Sequence Diagrams (SD) Tips (2 of 2)
How to add Requirements and Parametric KPI
1. Repeat from outermost flow, into their nested flows: Add ports to major single entry and single exit in SD
2. For each attest type (latency, )
3. Repeat from outermost flow, into their nested flows:
1. For each attest report from outermost, into nested flow flows:
2. Attach requirements to ports which are
Review:
• Sufficiently analyze your design’s coordination on SD before coding.
• Clean up the static model before proceeding to Lab3: Early Design Review.

IOTG56
OMG Certified Systems Modeling Pro (OCSMP)
Four Certification Levels:
1. Model User – using models from basic SysML
2. Model Builder Fundamental – build models from basic SysML
3. Model Builder Intermediate – build full SysML Language (tests SysML v1.2)
4. Model Builder Advanced – build beyond SysML
See www.omg.org/ocsmp

IOTG
Legal Notices and Disclaimers
Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies
depending on system configuration. No computer system can be absolutely secure. Check with your system manufacturer or retailer or learn more at intel.com.
Tests document performance of components on a particular test, in specific systems. Differences in hardware, software, or configuration will affect actual
performance. Consult other sources of information to evaluate performance as you consider your purchase. For more complete information about performance and
benchmark results, visit http://www.intel.com/performance.
Software and workloads used in performance tests may have been optimized for performance only on Intel microprocessors. Performance tests, such as SYSmark
and MobileMark, are measured using specific computer systems, components, software, operations and functions. Any change to any of those factors may cause
the results to vary. You should consult other information and performance tests to assist you in fully evaluating your contemplated purchases, including the
performance of that product when combined with other products. For more complete information visit http://www.intel.com/performance.
Cost reduction scenarios described are intended as examples of how a given Intel-based product, in the specified circumstances and configurations, may affect
future costs and provide cost savings. Circumstances will vary. Intel does not guarantee any costs or cost reduction.
This document contains information on products, services and/or processes in development. All information provided here is subject to change without notice.
Contact your Intel representative to obtain the latest forecast, schedule, specifications and roadmaps.
No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document.
Statements in this document that refer to Intel’s plans and expectations for the quarter, the year, and the future, are forward-looking statements that involve a
number of risks and uncertainties. A detailed discussion of the factors that could affect Intel’s results and plans is included in Intel’s SEC filings, including the
annual report on Form 10-K.
All products, computer systems, dates and figures specified are preliminary based on current expectations, and are subject to change without notice. The products
described may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata
are available on request.
Intel does not control or audit third-party benchmark data or the web sites referenced in this document. You should visit the referenced web site and confirm
whether referenced data are accurate.
© 2017 Intel Corporation. Intel, the Intel logo and others are trademarks of Intel Corporation in the U.S. and/or other countries.
*Other names and brands may be claimed as the property of others

Develop Future Proof IoT: Composable Semantics, Security, FuSa, and QoS

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Develop Future Proof IoT: Composable Semantics, Security, FuSa, and QoS

Similar to Develop Future Proof IoT: Composable Semantics, Security, FuSa, and QoS (20)

More from Intel® Software

More from Intel® Software (20)

Recently uploaded

Recently uploaded (20)

Develop Future Proof IoT: Composable Semantics, Security, FuSa, and QoS