Hi, Ben.
Nice work! I'm looking at this from the perspective of how can we collectively provide a way for rapid development of edge connectivity and capability, but still preserve true interoperability. I've lived through attempts in the industrial domain so can share battle scars and gotchas, and of course we've been doing things in the M2M space of late.
A few other thoughts come to mind for the "bigger picture":
- we should consider and support scenarios where the device/machine does not have a directly accessible IP address
- the basic capabilities from a wire/protocol perspective should be language and platform agnostic, such that it would be possible to write an implementation in java, c#, python, etc...
- we can address current shortcomings in existing protocols (e.g. limitations in time stamp precision, etc)
Again, great job!
Rick
Hi Rick, and thanks for the feedback!
A few comments/answers below.
> file transfer (upload log files, download config and software updates) Configuration and software updates are already handled by the Application Manager of Mihini. Logs can be transmitted on-demand, using FTP. File transfer in general is made possible by the underlying Lua VM (i.e. LuaSocket), but maybe it would make sense to provide an higher-level API that allows generic file transmission without mandatory knowledge of what protocol (FTP, HTTP, …) will be used on the wire.
> discovery is a MUST. discovery capabilities (data, services, events, etc) Agreed. In terms of data/events, the Data Manager exposes a data tree that can be monitored for changes. It would be interesting to see how the availability of services could be mapped on such a tree.
> generic framework for change-based notifications (detect changes based on value, deadband, time, etc) and for edge detection of alerts/alarms (numerical ranges, Boolean expressions, etc.) The initial contribution of Mihini will include a prototype of a monitoring framework that does exactly what you are referring to. It allows to connect custom or predefined triggers (onBoot(), onChange(var), onDate(cron), ...) to custom or predefined actions (sendData(), forceServerConnection(), …). While the "rules" are expressed in Lua at the moment, it'd probably be useful to support other representations.
> store and forward capabilities/qos The Data Manager allows to put into queues the data to transmit, and associate these queues with policies such as "send immediately", "send at least every hour", "send after 60sec of latency"… Also, prior to being transmitted, a queue can be consolidated (average, min, max, etc.).
> encryption support The protocol being part of the initial contribution of Mihini will allow encrypted communications, but one thing that should be considered IMO, is how we could address encryption/obfuscation of what is stored on the actual target (data, logs, binaries, …), so as e.g. an application from customer A cannot be accessed/modified/reverse-engineered from a non-allowed customer B.
Hope that gives you more information about what will be part of the initial contribution (note that for some of these features, the APIs are in a provisional state, and will have to be fine-tuned).
On a side note, should I add you to the list of interested parties on the project? :)
Benjamin.
I'd recommend including a few other capabilities:
- file transfer (upload log files, download config and software updates) - discovery is a MUST. discovery capabilities (data, services, events, etc) - generic framework for change-based notifications (detect changes based on value, deadband, time, etc) and for edge detection of alerts/alarms (numerical ranges, Boolean expressions, etc.) - store and forward capabilities/qos - encryption support Also, h as there been any further discussion on an embeddable Java server runtime for MQTT?
All,
I am very happy to share with you the proposal for a new Eclipse project [1], that we think will be a great addition to what already is available at Eclipse in terms of tools (Koneki) and communication protocols (Paho) for M2M. The goal of Mihini is to provide an embedded runtime that exposes Lua API that a developer can use to build M2M application easily. The APIs that Mihini will expose aim at facilitating the access to the network, the manipulation of the I/Os, smart transmission of M2M data, … and they should also allow to manage (start/stop/update…) the different applications running on a system. I believe this is a great opportunity for the IWG at large to seed the discussions on the definition of an M2M framework with a first concrete implementation.
I am very much looking forward to hearing your feedback on this proposal, as well as to answer any questions you may have. We will be using the upcoming weeks to collect community feedback, and gather interested parties (FWIW there is also a dedicated thread [2] on Eclipse Proposals forum), so please feel free to share your thoughts!
Also, I'd be happy to discuss the proposal further during our weekly call next Tuesday.
Regards, Benjamin
|
