1 / 20

Sensors to Servers

Sensors to Servers. Meeting #2: February 27, 2014. IoTCM : IoT Connection Model. Meeting Goals. Mission The need for a spec Example scenario What is IoTCM ? What will 1.0 Cover “The Plan” (schedule and milestones). The Mission Has Not Changed.

tadhg
Télécharger la présentation

Sensors to Servers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Sensors to Servers Meeting #2: February 27, 2014 IoTCM: IoT Connection Model

  2. Meeting Goals • Mission • The need for a spec • Example scenario • What is IoTCM? • What will 1.0 Cover • “The Plan” (schedule and milestones)

  3. The Mission Has Not Changed • To provide a recommended set of standard terms and interfaces to allow nodes in heterogeneous systems to communicate at a basic level while leaving implementers free to extend and add value in any way they choose.

  4. Why Another Spec? • Existing specifications focus on transporting “values” rather than the information needed for integrating disparate systems. • A value of “42” is useless. “42 C” is useful. • “False” is useless. “Valve is closed” is useful. • “1.2” is useless. “1.2 Amperes” is useful. • We need a spec that includes context and semantics with the value

  5. Why Another Spec? • Existing specifications are typically proprietary, even if they are “open”. • Leads to system “islands” and an Internet of My Things (IoMT) instead of true IoT • We need a spec that is vendor and vertical agnostic. We don’t care where the data comes from or goes to, in fact it should be transparent.

  6. Why Another Spec? • Current specifications have barriers to entry such as requiring purchase of specifications, closed source libraries and/or patented transport protocols. • Stifles innovation and adoption • Leads to only “big players” in many industries, excludes small vendors, students, etc • Again, leads to IoMT systems • We need a spec that completely free and open.

  7. Simple Scenario? • A software developer has the following 3 situations: • A building with a known latitude and longitude and a zigbee temperature sensor in it. • A municipal bus with a proprietary serial dead-reckoning device that provides location and a J1939 temperature sensor • A factory service tech with a tablet that has a GPS and a USB connection to a thermocouple • How does he or she create one application that can show the location on a map and the temperature on a gauge?

  8. Simple Scenario? • Now: • Write a library to get the Zigbee data, convert that into temp. Allow the user to hand-enter the position. • Write a library that speaks “CAN” and sets the bus filter, reads the temperature. Create a serial library that reads the dead-reckoning device. • Create a library to read the GPS and a library for the proprietary thermocouple device. • Integrate all of that data into the app • A couple months from now: • Use a provided Client library that implements the spec to read the common Temperature and Location Things

  9. What is IoTCM? • It’s all about • Things IoTCM Host Thing Things Data Data Methods Methods

  10. What is IoTCM? A “Host” implements the spec. A “Client” consumes it. IoTCM Host IoTCM Client IoTCM Client Things Thing Interfaces Thing Interfaces Network (WiFi, Cellular, etc.) Thing Data Method Calls

  11. What is IoTCM? • It’s like a bus specification • Connects disparate devices with different protocols from different vendors • Provides a common communication standard • Gives standard structure to the data so it’s not “just numbers” but has context • Allows devices to be found and their capabilities identified • Consider the USB Camera • Manufacturer is not important • How the camera gets data from the CCD and mic is not important • We can determine if it has a mic, supported image size, frame rates, etc. all because it uses a standard

  12. What is IoTCM? OPC Tag Point “42” Temp Sensor Temp Sensor Temp Sensor IoTCM Client IoTCM Client Thing Interfaces Thing Interfaces 5.736 mA BACnet Tag “42” Proprietary Inputs IoTCM Host Network (WiFi, Cellular, etc.) Things Motor Standard Outputs 42 C

  13. What IoTCM Looks Like Standard Semantics Standard Units Standard “Thing” Accessibility Standard Data Types

  14. What IoTCM Looks Like Data Capture Time Data Set Data Source Thing Data Values

  15. Important Distinctions • Context is the key • Not just Values, but also Structure tied to a spec • Data and Transport are separated • XML/JSON/proto-buf could just as easily pass over Zigbee, RS232, RS485 or whatever • Infinitely Extensible • Implementers can (and are encouraged to) add attributes, nodes, etc. for their own added-value • Common Collection of “Things” (the Thing Library) Allows Interop • Provides common descriptors for basic services and data of well-known Things • Can be extended by industry and vertical experts • Implementers can create their own Things • Security is Transport-related • Will implement basic role-based session security in v 1.0 Reference Implementation • Implementers can add encryption, security, etc. as they see fit (HTTPS, SSL, etc.)

  16. Important Distinctions • Temporal Consistency is Implementer Responsibility • When a Client asks for Data, the Host provides a Value set. The implementer determines temporal consistency. • Structure and Values are Separate • Structure is queried on discovery (and instance change) • Data is queries far more frequently • Client is responsible for matching Values to appropriate Data • Storage and Persistence are optional and Implementer-Defined • Spec covers “what is the value right now” • Version 1.0 *may* propose an API for historic value retrieval, depends on time and resources • Did I mention “free and open”? • No cost to download, implement, use or distribute. • Full source SDKs provided. • Public participation encouraged. • As open a license as we can have (probably MIT)

  17. Starting Small • We do not need to solve all problems. • It would take a long time • It would be vertical-centric • It would fail to achieve the mission • We simply need: • Basic Data Transfer • Basic Behavior (functions) • Basic Discovery • Not all data or behaviors available on a Thing need to be in the spec. • Keeps things simple, makes the spec agile • Leaves room for innovation and added value

  18. What will be in v 1.0? Specification of Components • Things • Data • Functions Data Access over IP • REST interface definitions • XML • (Maybe JSON or proto-buf?) Discovery • Details to be worked out History • Maybe, but more likely 1.1 Thing Library • Definitions of common Things SDKs and Reference Implementations • C# Host and Client

  19. The Plan • Completed: • Begin Spec Document • Begin SDK and Reference Implementation • Next 4 weeks • Start the Thing Library • Register Domains, Publish Projects and docs • Get others involved (working groups, editors, developers) • April-May 2014 • Find implementers and early adopters • June 2014 • Publish 0.9 and solicit feedback • August 2014 • Publish 1.0

  20. Questions, Feedback, Volunteers ctacke@opennetcf.com (240) 293-4633 Coming Soon: http://www.iotcm.org

More Related