A while ago I was approached by a few people who wanted to work together on a new protocol for use in web based HMI systems (and other similar applications). They had a SCADA system and I had my own automation projects and we both wanted something which was simple and easy to implement, but which offered good support for HMI and SCADA applications.

What we came up with is a protocol which we call "Cascadas". I have published a draft copy of the protocol here:

http://mblogic.sourceforge.net/mbhmi/mbhmiintro.html

If you scroll down the page, you will see a link to the PDF document under "Protocol Specification". I haven't provided a direct link to the PDF document itself because I intend to update that from time to time. The link should be easy to find on the page though.

We are looking for any feedback and comments on the protocol to help improve it. It is intended to be an open specification that anyone can implement freely.

The protocol is intended to be *simple* and *easy to implement* but still offer features which directly support higher level HMI functions (e.g. alarms). It can also be used for things such as integration with MRP/ERP systems. The protocol is designed so that feature subsets can be implemented if you don't need the whole thing.

This protocol is in use today (for example in my own web based HMI systems), so this is a working, practical protocol. I am using an HTTP transport, but the protocol itself can also be sent directly over TCP or UDP sockets with a conventional (non-web based) HMI.

We are looking for review and comments on this. We would like this to be an open protocol that is adopted by other people in their own applications. If anyone is interested in implementing this protocol in their own applications I would be glad to help them out. This is not just for open source projects. Proprietary software vendors are welcome to use it as well.

I would appreciate any comments anyone may have on this subject.

 

Good show!, Michael etal.

I for sure will take a look, later this week. I'm curious what you will do for licensing. Not for the larceny usually associated with licenses in this industry, but to keep it free, and hopefully discourage proprietary "enhancements".

Regards,
cww

 

It's an open protocol. If someone wants to extend it, I'm not going to try to stop them. Even if I was so inclined, I don't have a team of high priced attack lawyers anyway.

If someone comes up with some new ideas and they happen to be good features and useful to other people, we can add them to the spec. There's nothing wrong with subsets either. There are a couple of minor features that *I* haven't implemented because while the other parties wanted them, they weren't something I thought was useful for my applications.

If you have a look at the protocol I think you'll be surprised at how simple and obvious it is while still incorporating a lot of high level concepts. It's also designed so that it *can* be extended while still remaining backwards (and forwards) compatible. If someone wants to add their own undocumented extensions they would probably be pretty trivial to reverse engineer, so there's not a lot of scope here for vendor lock-in.

Anyone who doesn't want to be inter-operable will probably come up with their own obfuscated monstrosity rather than copying us. The usual suspects already *have* their own obfuscated monstrosities, so I don't think they'll have too much interest in what we have to offer.

For anyone who just wants to stick a nice easy to implement web based HMI on their system that can take advantage of existing libraries and clip-art, or who is looking for an easy to use ERP/MRP interface though, this spec has a lot of attractions. There is no value in making this sort of thing proprietary.

There's nothing in it that's a work of genius. We made a deliberate effort to avoid doing anything too clever. It's all based on existing open standards and concepts that have been widely used in the Internet world for years. The actual protocol encoders and decoders are in the standard libraries of a lot of popular programming languages. We've simply picked out those commonly used Internet standards we thought were useful and applied them in a way that is useful in this problem area and then documented the result.

Our industry is generally so backwards that we are slow to adopt new ideas. I think the interest is there now though.

 

First! Thumbs up for putting a massive effort into this project and releasing it to the open source community.

The name cascadas is used http://www.cascadas-project.org/related.php - their project description is fairly vague imho and could mislead anyone searching for your protocol.

I was also expecting to find something in the 'communications' section of your web page. I did not expect to find it under the HMI section.

My personal opinion is that alarms should be normal tags, and a tag should also sometimes be a hash.

I am also not sure whether alarm history is a concept that should be described specifically by the protocol.

Other than that (which is really minor stuff): EXCELLENT WORK!

 

As far as the web site is concerned, I will be revamping that area to reflect the recent work I have been doing. The protocol spec is in the "HMI" section because it is HMI related. I will have a look at putting a link to it directly from the front page when I have that area redesigned.

As far as alarms not being normal tags, there are a number of reasons for them being treated specially. For one thing, it allows extra data to be attached which is relevant to the alarm.

For another, it minimizes the amount of data being transferred between the server and the client. That was a concern for some parties, so we took some pains over this. Large numbers of alarms can be monitored by simply referencing their "zones". If there are no alarms to report, then no alarm tag information needs to be returned.

In addition, the alarms are automatically summarised and categorised as to active, active but acknowledged, inactive but not acknowledged, etc. When they change state that is automatically and inherently reflected to all the other workstations without them having to communicate directly with each other. Alarms automatically go from the active display area to the alarm history area, so you can get a quick overview of what has been happening recently.

If you want a particular data point to be both an alarm and a regular tag, it is quite straightforward to do that as well. If you want to monitor for a specific alarm and take action on that (e.g. flash a light), that will be possible as well via a new feature that I am just finishing up for someone (it's a change in the client libraries, not the protocol).

As for alarm history (and alarms themselves, and events), the thing to keep in mind is that this is a high level application protocol. A server monitors the data and categorises it. A client only has to worry about presentation and can be just a very thin layer over the protocol itself. That makes a system very easy to implement, which is one of the major design goals.

What is more, subsets of the protocol can be used if that is all you need. If you aren't interested in alarms or events, you just don't have to ask for any.

I'm not sure what you mean though when you say "tag should also sometimes be a hash". Could you elaborate on that a bit?

Thanks for the positive comments on this. I think it's quite suitable for a lot of applications and hope that other people decide to make use of it.

 

> I would appreciate any comments anyone may have on this subject. <

I looked at the Cascadas spec and enjoyed. I like it better than the OPC spec. I would however suggest two additions:

- support for historical trending. This can be included into the event model you already have. You only need to add a range (start timestamp, end timestamp).

- support for database access: many HMI applications basic methods to get access to structured data. Examples are recipes and reports.

Does that fit into Cascadas scope?

 

The Cascadas protocol is intended for "live" data that updates on the HMI screen as you watch it. The goal was to keep focused, keep things simple, and try to do well the things that 99% of people want. Adding everything plus the kitchen sink to a protocol results in a monster of a spec that no-one can implement properly.

We discussed historical database access and recipes, but decided to not address them. Things like that are handled very well by conventional web applications and there is no value added by layering another protocol on top. Now there can be a case for creating a framework for making things like recipe handling applications easier, and that is something that I have plans to address eventually. However, we didn't didn't see any value in making that part of the Cascadas protocol.

The alarm and event history features in Cascadas are just there to give the operators a quick view of the most recent history. The server can buffer that in memory so there is no load on the database (if you have one) just from routine HMI use. In a lot of simple machine control applications there wouldn't even be a historical event or alarm history database.

You can do live strip charts right now (the demo screen that I ship with my software has one) that simply plot the value of a register over time. We discussed adding time stamped and array data to do XY charts, but nobody had an actual case they could think of where they would use it. If it turns out that is a feature that a lot of people would use, we can discuss with them how it could be added to the spec in a way that is useful to them.

Thanks for the positive comments.