BlueRithm - Improve Quality, Accelerate Deliverables, Save Time and Money
EMAIL INTERVIEW – Tony Marshallsay and Ken Sinclair
Tony Marshallsay is a Chartered Mechanical Engineer (US=PE) who has spent many years designing and supervising the installation of building services and building automation systems for major construction projects in the Middle East. Now retired, he maintains a keen interest in BAS and has also become a registered UK STEM Ambassador.
You may remember that some time ago I pitched to you a common data protocol based on IP. Well, a couple of days ago Memoori gave me the opportunity to present it as a webinar. You can catch the recording, slide show and accompanying description (which you should download, print and have in hand, so you can follow the recording) here: http://www.memoori.com/audio-dont-real-ip-edge/ In it, I explain why the IoT is slow getting off the ground, after all the hype, which ties in well with your tweet about 2017 not being the year of IoT.
You say you're not in the controls
business, Tony, so how do you come to be making a pitch for this system
that stabs at the heart of it?
Marshallsay: Well, over the 30 years or so that I've been designing and supervising installation of BAS in large building projects, I've seen the number of suppliers, and of their proprietary data transmission methods, protocols, and programming languages, grow and grow, then shrink again as consolidation of the market took place. But still, when a new building is designed, the chances are its BAS will be a conglomeration of proprietary and open systems. That won't do in the future.
Middleware like Niagara has permitted a
common User Interface at the Central Monitoring Station or a Field
Technician's laptop, but it hasn't removed the need for multiple steps
of protocol translation as the data passes through the various sections
of a network. That's the killer.
Sinclair: But these mixture systems work all right, don't they? Why do you want to introduce what promises to be a really disruptive change?
Marshallsay: They work well if you're comparing one mutt of a system with another, but comparing any one (BAS) with RIP2E - REAL IP to the Edge - is like comparing a nag with a thoroughbred racehorse: the difference in performance is just what you'd expect.
The IoT BAS of a future smart building will have hundreds more connected devices than today, so will have to run much faster to keep the bigger traffic flow moving. RIP2E's Internet Universal Protocol (IUP) can do that because it runs more than twice as fast as "business as usual" BAS.
Today's style of system simply won't
do. The wired or wireless transmission is instantaneous, but
rearranging data between protocols takes a lot of processing, which
slows everything down. Moving to IUP could get rid of most of that
delay and my analysis proves it.
Sinclair: The analysis and performance figures are impressive but will IUP really work that way?
Marshallsay: Its function is the same as any other data protocol; but instead of proprietary formats, the "From - To" header uses IPv6 addresses and the data section fits an IPv6 envelope. So, an IUP packet will look like any other IP packet.
Most importantly, instead of being chewed up and spat out at each network controller, it will just be switched from line to line by a regular IP router. That means unlimited data storage, analysis, and control programming can be anywhere in the network.
A regular BAS data point has a point ID,
a type ID (e.g. temperature), a unit ID (e.g. degree C - as far as
possible, IUP will be only metric) and a value. IUP will still need the
point ID but, to cover the range of existing data protocols and any
that may evolve in the future, it will prefix the type ID with a "code
page" tag, like Unicode.
The lengths of the segments of the data section will be fixed, because fixed formats are what make accessing and processing the content of big databases super-fast; and the total length will be as small as possible, for economical processing by tiny smart devices on the Edge harvesting ambient RF power.
And Operator Work Stations or their portable equivalents will use IUP directly.
Designing the data section will be no easy task, but it’s an important and necessary one.
Isn't your IUP going to put a load
of noses out of joint?
Marshallsay: I'd be surprised if there's any BAS player that hasn't done the analysis I have and reached the same conclusion. They're likely making hay while the sun shines until the IoT crashes. Then the story will come out, and they'll have to bite the bullet.
By showing the difference RIP2E could make, and the extra savings from using it with the end-to-end encryption needed to prevent hacking via IoT edge devices, I hope to save some pain.
There won't be networked controllers anymore, but control software will still be needed, so the present BAS suppliers could become much more active there.
And when data processing can't be avoided, the faster it can be done, the better. So, I expect competition in that area, with lots of new software engineering jobs.
An important takeaway is that, although the data protocol will be completely agnostic, attractive, efficient and niche UIs, and the usual add-on service and analysis packages - which can be as proprietary as they like - will still be needed. And future BAS customers will be looking at how well A's system performance, UI, and data management packages offer compares with that of B, so a savvy specifier could match A's system data handling with B's front end to create a really smart building.
Okay. Last question - the
inevitable one, I guess: Where do we go from here?
Marshallsay: RIP2E is mostly about speeding up BAS data transmission as much as feasible - but that's not the whole story. Other factors to be considered are:
I think we're going to need AI sooner rather than later, to analyze and optimize systems with so many variables.
It was recently suggested that the world would run out of power by 2040. RIP2E has the potential to "kick the can down the road a ways" - hopefully until there's enough sustainable power in the mix that we don't need to worry about carbon emissions anymore.
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]