Going with HAL + Protocol Buffers vs Thrift?

[ferrisoxide]

Hi folks

I'm assuming people are comfortable with HAL as the default representation format for XML / JSON data. There hasn't been any conversation about this - though I suspect that's mainly because interested in XPCA has died away. In any case, I'm making a call on this. People are welcome to disagree.

The main argument for HAL over say JSON API is that HAL supports both XML and JSON representations. I want XPCA to be "multi-protocol" in that we should be able to support both. A secondary argument is that HAL has been submitted as a candidate IETF standard (see https://tools.ietf.org/html/draft-kelly-json-hal-07). If it gets ratified then it's line with the XPCA design principle of reusing existing standards or conventions over inventing new ones.

So, if there's no further discussion I'm going ahead with a trial mapping of Modbus to XPCA using HAL. It doesn't prevent using JSON API or similar in the future, as each request should include the media type (in this case application/hal+json or application/hal+xml).  

Which brings me to the next question. XML and JSON are still bulky over the wire. I've been looking at Protocol Buffers as an alternative format for compact message passing, but Apache Thrift also has appeal. BSON has merit as well, but it's not as compact (but is similar enough to JSON to make it interesting). Has anyone used any of these in process control - or know of where these have been used in the past?

There's a host of data serialization formats available. Obviously we don't want to try to support too many formats, but at some point we need to make a call. Anyway, here's a list of possible formats: https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats

Maybe I'm getting ahead of myself - and probably prematurely optimising. I'll focus on JSON and XML for the time being, but I'm pretty sure we'll have to think about a more compact format in the future.

Cheers

Tom  

[Aleksey Timin]

Hi Tom,

I've never used HAL actually. I had a bit of a look at the specification and I didn't mange to figure out how it could be useful to work with industrial protocols (e.g. Modbus). Most of the protocols have a flat structure of addresses or points. In my opinion they don't need any additional tools to navigate through the data. When I configure a SCADA project and connect it with a PLC, I always know where the needed data is placed by using the project specification. Maybe I miss something. Could you give an example HAL-JSON for ModBus?

Concerning the data serialization formats in process control, I've never used ones. Most of the protocols (including OPC-DA) don't need that because they are binary initially. There are OPC-XML and OPC-UA that using SOAP, but I haven't seen their implementation in action yet and can't say if they need some compression. Actually I don't think XPCA should use that. As for me the best XPCA's feature is a clean widely used format of data based on a plain text.

What I am really worry about is an implementation of the producer\consumer conception in XPCA. There are some industrial protocols such as (DNP3, CIP ItherNet\IP etc.) that use unsolicited messaging. As I can see XPCA looks here very limited because of HTTP.

Cheers

Alexey

пт, 4 дек. 2015 г. в 2:43, ferrisoxide <ferri...@gmail.com>:

--
You received this message because you are subscribed to the Google Groups "xpca" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xpca+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ferrisoxide]

Hi Alexey

You are right - mapping Modbus to XPCA doesn't make sense. XPCA should really live at a higher level, exposing resources like boilers, switches, etc - not at the lower machine-to-machine level.

The idea with HAL is to allow for auto-discovery of resources as hypermedia / HATEOS resources. I.e. you can examine the links available via an xpca endpoint to reach other resources. In this sense it's more meaningful to compare xpca resources with the notion of 'nodes' in an OPC UA model.

Where XPCA differs from OPC UA is that it is effectively schema-less. I think I need to focus on the value-proposition of XPCA (a simple, lightweight alternative to OPC UA) and forget about low-level stuff. Obviously there needs to be a mapping from Modbus and similar protocols, but that would be the purpose of an XPCA server - effectively hiding all the low-level interaction and presenting a more refined model to be consumed by SCADA interfaces. I think I was looking at 

I need to find a "classic" application to model in XPCA and prove the overall concept. I've found a lot of examples for OPC use the same typical boiler / flow control / etc model. I'm not where this comes from, but it seems like a good place to start. Example:   

http://www.commsvr.com/OPC-Help/html/e6a0a08f-6abc-46c4-8fad-10e586fbac71.htm

If anyone can think of a better "classic" example to use I'd be interested in knowing more.

On the issue of Thrift vs. Protocol Buffers, in general the latency in HTTP shouldn't be an problem for HMI type applications. If we're using JSON or XML the overhead would be similar to or perhaps less than an OPC UA XML packet. But OPC UA does have a binary format for places where you need higher performance - and I guess I was getting ahead of myself.

In any case, thinking about all this has made me think about other important stuff. This is the first time I've mentioned XPCA being schema-less - because it's the first time I've really thought about it. While I'm not sure that is super important, it raises some possible design issues going forward. For instance, if we say that schema-less models is a design constraint then it rules out both Protocol Buffers and Thrift as a binary format (both are schema-oriented protocols) but it does allow for something like BSON - at the cost of efficiency over the wire.

Whatever the case, I'm still getting way ahead of myself. The next goal should be to create an example project that presents how XPCA should work. The boiler one makes sense, but if there is a better example... It'll make me have to address how XPCA will handle different scenarios, so maybe if we can cover two or three different applications it can help present the case for XPCA better. As a side note, I'm not too keen to compare XPCA to OPC UA too much. I think they serve different purposes. But if there are common models that can be presented side-by-side (like the boiler example) then it will help to demonstrate where XPCA is a better fit and where it isn't.

Cheers

Tom

To unsubscribe from this group and stop receiving emails from it, send an email to xpca+unsubscribe@googlegroups.com.