BAS - RAILWAY

ANALOGY

Present BAS IoT with REAL End-to-End IP

Rail Travel in UK Today BAS Equivalent

One Standard Rail Travel IoT Equivalent

Blaenau-Ffestiniog Field Controller Expansion Module Blaenau-Ffestiniog Smart Device

Passengers board train carriage Analog and Binary signals hard-wired to FC XM Analog and Binary signals translated to digital data Data put into FBP packet

Passengers board seating container on flat wagon

Analog and Binary signals hard-wired to SD Analog and Binary signals translated to digital data Data put into IUP packet

Blaenau-Ffestiniog to Porthmadog Expansion Module to Field Controller

Blaenau-Ffestiniog to Porthmadog Smart Device to Local Router

Steam, narrow gauge, passenger carriage

Proprietary FB Proprietary FBP

Steam, narrow gauge (NG), NG flat wagon + container

Generic LB IUP

Porthmadog Field Controller Porthmadog Local Router

Passengers change platforms Data shifted to FC memory Data translated to BBP

Container craned from NG flat to standard gauge (SG) flat

Packet transferred as is to Generic Branch Bus

Passengers board branch line diesel railcar

Data put into BBP packet

Porthmadog to Shrewsbury Field Controller to Branch Controller

Porthmadog to Shrewsbury Local Router to Branch Router

Diesel, standard gauge, passenger railcar

Proprietary BB Proprietary BBP

Diesel, standard gauge, SG flat + container

Generic BB IUP

Shrewsbury Shrewsbury

Passengers change platforms Data shifted to BC memory Data translated to MBP

Flat wagon + container changes tracks

Packet transferred as is to Generic Main Bus

Passengers board regional train carriage

Data put into MBP packet

Shrewsbury to Wolverhampton Branch Controller to Main Controller

Shrewsbury to Wolverhampton Branch Router to Main Router

Diesel, standard gauge, passenger carriage

Proprietary MB Proprietary MBP

Diesel, standard gauge, SG flat + container

Generic MB IUP

Wolverhampton Main Controller Wolverhampton

Passengers change platforms Packet data shifted to MC memory Data translated to OP

SG flat + container changes tracks Packet transferred as is to Building Bus (IP Backbone)

Passengers board Inter-city train carriage

Data put into OP packet

Main Controller to Gateway

Proprietary MB OP

Gateway

OP packet wrapped inside IP packet

Wolverhampton to London (Euston)

Gateway to Building Controller (BCMS)

Wolverhampton to London (Euston)

Main Router to Building Controller (BCMS)

Electric, standard gauge, Inter-city carriage

IP backbone IOP

Electric, standard gauge, SG flat wagon + container

IP backbone IUP

London (Euston) Building Controller (BCMS) London (Euston) Building Controller (BCMS)

Passengers disembark and change platforms Passengers transfer to St. Pancras International Passport and Customs checks

IOP packet copied to BCMS memory IP packet unwrapped OP translated to MWP MWP data display on BCMS VDU

Passengers remain in container On-board passport and customs checks

IUP packet copied to BCMS memory IUP data display on BCMS VDU

Passengers board ES carriage Packet transferred as is to Internet Container craned from SG flat to ES flat

Packet transferred as is to Internet

London (St Pancras Int'l) to Paris Building Controller (BCMS) to Campus Controller (CCMS)

London (St Pancras Int'l) to Paris Building Controller (BCMS) to Campus Controller (CCMS)

Electric, ES, passenger carriage Internet IOP

Electric, ES, flat wagon, container Internet IUP

Paris (Terminus) Paris (Terminus)

Passengers disembark Packet data shifted to CCMS memory IP packet unwrapped OP translated to MWP MWP data display on CCMS VDU

Packet data shifted to CCMS memory IUP data display on CCMS VDU

Glossary

Controllers

SD Smart Device Converts Analog & Binary signals from built-in sensors to IP data

XM FC Expansion Module Converts Analog & Binary hard-wired signals to FB data & vice versa

FC Field Controller Controls and monitors "dumb" sensors, actuators, lights etc.

BC Branch Controller Controls traffic on BB connecting several FCs

MC Main Controller Controls traffic on MB connecting several BCs

GW Gateway Wraps MBP or OP data packets in IP envelopes

Data Buses

FB Field Bus Connects sensors or actuators to FC via XMs [Flat ribbon cable]

GLB Generic* Local Bus Connects SDs to LR [Various cable systems]

BB Branch Bus Connects BCs to FC [Various cable systems]

GBB Generic* Branch Bus Connects LRs to BR [Various cable systems]

MB Main Bus Connects BCs to MC [Various cable systems]

GMB Generic* Main Bus Connects BRs to MR [Various cable systems]

IPB IP Backbone (Building Bus) Connects GWs to BCMS [Ethernet Cat 6 cable or fiber]

* Generic buses usually originate as various manufacturers' proprietary buses but become "industry standard" by providing

the best fit of characteristics for a specific area of application. For instance, some BMS suppliers regularly talk about

"BACnet over LON", in which the former refers to the data protocol and the latter to the transmission medium.

Protocols

IOP Internet Open Protocol OP data packet wrapped in IPv6 packet

IUP Internet Universal Protocol Proposed data protocol designed to fit IPv6 packet format

FBP Field Bus Protocol Proprietary data protocol used on FB

BBP Branch Bus Protocol Proprietary data protocol used on BB

MBP Main Bus Protocol Proprietary data protocol used on MB

OP Open Protocol Open data protocol [BACnet, Modbus, LonWorks,…]

MWP Middleware Protocol Common data protocol for central monitoring [Niagara…]

Central Control and Monitoring Stations Rail Systems

BCMS Building Control and Monitoring System NG Narrow gauge SG Standard Gauge

CCMS Campus Control and Monitoring System ES Eurostar

UK - USA Equivalence

UK Rail Journey USA Air Journey

Blaenau-Ffestiniog Brownsville, TX

Porthmadog San Antonio, TX

Shrewsbury Dallas-Fort Worth, TX

Wolverhampton Atlanta, GA

London, Euston New York, LaGuardia

London, St Pancras International New York, JFK

Paris, Gare du Nord Paris, CDG

-

REAL IP to the Edge

Map Description

The intention of the map is to act as an analog of a large BAS network and what is now called "The

Cloud".

In such a network, the most remote device is, say, an analog (platinum or NTC) temperature sensor

wired to a smart Expansion Module which sits - perhaps physically - on the proprietary local bus of a

Field Controller and talks to it using a proprietary data protocol.

That Field Controller is in turn, with its peers, connected via a different proprietary bus and data

protocol to a Branch Controller.

The Branch Controller is in its turn, linked to a Main Controller via another, again using a different,

higher level, proprietary bus and data protocol.

The temperature message from the Field Controller has yet to reach the Building Control and

Monitoring Station (BCMS); but to get there it has to go through a couple more steps.

First, because the BCMS has to deal with messages from all sorts of systems, it cuts down the work of

the Middleware it uses to do that by insisting that all messages use one or other of a very limited set

of open or semi-open data protocols. So, the Main Controller has to translate the message from the

supplier's proprietary protocol to, say, BACnet.

It's then the job of the Gateway, which can connect to the supplier's high level bus, to wrap the BACnet

message in an IP envelope, ready for transfer to the building's IP backbone, which will take it to the

BCMS.

There, the IP package must first be unwrapped to reveal the BACnet message, which is then passed to

the Middleware, which translates it into its own - also proprietary - universal data protocol for display

on the Visual Display Unit of the Operator Workstation, and stores the content for record, analysis or

onward transmission to "add-on" software packages for billing, work order generation etc.

The temperature information message also has further to travel: to the Campus Control and

Monitoring Station (CCMS); but this time it's easier. The IP envelope, with its contents, is duplicated

and sent to it over the Internet. There, the same processes occur as at the BCMS, but the post-

processing will be strategic rather than tactical.

One point is important to remember: each message has two basic divisions. There is a header, which

holds the "from" and "to" addresses; and the content, which is defined by the data format and says

what type it is - in this case an temperature value - and the digital representation of that value.

At each change of protocol, these two divisions are dealt with separately, then combined to constitute

the translated message. This process is shown in the spreadsheet description.

It covers an area of the UK that is familiar to me and schematically represents the railway route linking

the fringe - Blaenau Ffestiniog, one of the most remote places in the UK and equivalent to the most

downstream smart device on a present BAS network, an expansion module for a field controller.

Now, looking at the upper map, imagine our group of football fans assembled at the station in Blaenau

Ffestiniog, one of the most remote locations on the UK railway network, deep in the mountains of

North Wales and served by a narrow-gauge track originally laid to transport slate from the area's

quarries to the coastal town of Porthmadog for coastal shipping to other parts of the UK and onward

to foreign parts.

The group has a ticket for the journey to Porthmadog and board a passenger carriage.

At Porthmadog, because the Ffestiniog Railway's narrow gauge rolling stock doesn't fit the main

network's Standard Gauge, they have to change trains: step down to the platform, then move to

another, while the group leader gets a ticket for the next leg of the journey to Shrewsbury. Then they

all board a branch line railcar - but the seating arrangement isn't the same as in the Ffestiniog carriage.

At Shrewsbury, it's a similar story - a new ticket and a new seating arrangement in the carriage of a

main line train - and it's the same again at Wolverhampton, but with an extra step. As well as changing

to a new ticket and a new seating arrangement, there's an Inter-City supplement ticket.

At London Euston, the terminus of the Inter-City Line, the group leaves the train, and their tickets and

the passenger list are checked and copied before they transfer to London St Pancras International, the

UK Terminus of the Eurostar train which will take them to Paris.

On arriving at Paris Gare du Nord, their destination, the tickets and passenger list are handed over and

the group can leave the station to go watch the match they came to see.

For the US air equivalent, Brownsville, Texas is the southernmost point in the lower 48, while

LaGuardia (or maybe Newark, NJ) and JFK stand in for Euston and St Pancras.

I expect everyone here has experienced the same sort of processes on any multi-stage rail journey at

interchange rail stations or on multi-leg flights at hub airports. It takes time to get from one rail

platform or airport gate to another, to say nothing about layover time waiting for connections, which

in BAS terms is equivalent to message packets stacked in a processing queue.

Now, it's time to look at the lower map.

The first thing to notice is the tracks are all green. That's because this is REAL IP to the Edge.

What I've called the Internet Universal Protocol still consists of two divisions - header and content;

but now the "from" and "to" addresses in the header are standard IPv6; and the content is formatted

to a standard length.

As well as that, the content is itself subdivided into two sections: a "Code Page" header determining

what discipline the data belongs to - HVAC, Electrical, Lighting, Security or whatever - and, as

previously, within that discipline the type and value of the data. The intent is that the code pages will

replace all the various special-purpose protocols which now exist.

At the start of their journey, the group now get one ticket which will take them the whole way to Paris,

and their journey will be much more comfortable, because, instead of swapping between a lot of

different rail carriages, they will board a large shipping container which has been fitted with seats,

windows and "all mod cons". And at each interchange they'll just sit still and enjoy the view as the

container is lifted from one flat wagon and set down on another on the next system. They'll only have

to get up again when they reach their destination.

Now, isn't that a LOT simpler?

In IoT terms, The IUP packet is filled by a smart device at Blaenau Ffestiniog, only having its destination

read at each router before being switched to the next leg of the route. There's no need for

Middleware, because the BCMS and CCMS Operator Work Stations will read IUP directly.

And, while in analog terms the rail line from Blaenau Ffestiniog to Porthmadog could be replaced by a

sky crane chopper, in IoT terms the equivalent would be a wireless network.

[Oddly, it happened that I mentioned this webinar to Dr. Steve Methley, a member of I-triple-E, when

we were discussing a STEM education event, and he was kind enough to point me to a Wikipedia

article on an initiative called 6LoWPAN. It concerns the implementation of, and security in fringe

networks consisting of small-format smart devices powered by harvesting ambient RF power.

He was concerned about the additional processing involved in using IPv6 right to the edge; but in the

article I found this statement related to addressing:

"The management of addresses for devices that communicate across the two dissimilar domains of

IPv6 and IEEE 802.15.4 [a special protocol developed for these networks] is cumbersome, if not

exhaustingly complex."

To my mind the solution is simple: use REAL IP to the Edge and limit device processing by just looking

at or loading only that [final] section of the IPv6 address which applies to the LoWPAN.]

Now, let's see what IUP can do for IoT.

[Continue to Slide 17]

BAS Operations

A-D

Process

Pack/Unpack

Wrap/Unwrap

Add/Read Tag

Send

NOP

IUP Operations

A-D

Process

Pack/Unpack

Wrap/Unwrap

Add/Read Tag

Send

NOP

BAS - IUP Operations Comparison

BAS (Multiple Data Protocols) IUP (Single IP-based Protocol)

XM SD

A-D Conversion A-D Conversion

Pack in FBP case Pack in IUP case

Add FBP baggage tag Add IP baggage tag

Send to FC Send to LR

FC LR

Read FBP baggage tag Read IP baggage tag

Unpack FBP case NOP

Repack into BBP case NOP

Apply BBP baggage tag NOP

Send to BC Send on to BR

BC BR

Read BBP baggage tag Read IP baggage tag

Unpack BBP case NOP

Repack into MBP case NOP

Apply MBP baggage tag NOP

Send to MC Send on to MR

MC MR

Read MBP baggage tag Read IP baggage tag

Unpack MBP case NOP

Repack into OP case NOP

Apply OP baggage tag NOP

Send to GW NOP

GW

Read OP baggage tag NOP

Wrap OP case inside IP case NOP

Apply IP baggage tag NOP

Send to BCMS Send on to BCMS

BCMS BCMS

Read IP baggage tag Copy IP case and baggage tag Read IP baggage tag Copy IUP case and IP baggage tag

Send to CCMS Send to MW Send to CCMS Send to IUP OWS

MW

Unwrap IP case NOP

Read OP baggage tag NOP

Identify OP NOP

Unpack OP case NOP

Repack into MWP case NOP

Apply MWP baggage tag NOP

Send to MW OWS NOP

MW OWS IUP OWS

Read MWP baggage tag Read IP baggage tag

Store source and destination Store source and destination

Unpack MWP case contents Unpack IUP case contents

Format for VDU display Format for VDU display

CCMS CCMS

Read IP baggage tag Copy IP case and baggage tag Read IP baggage tag Copy IUP case and IP baggage tag

Send to MW Send to IUP OWS

MW

Unwrap IP case NOP

Read OP baggage tag NOP

Identify OP NOP

Unpack OP case NOP

Repack into MWP case NOP

Apply MWP baggage tag NOP

Send to MW OWS NOP

MW OWS IUP OWS

Read MWP baggage tag Read IP baggage tag

Store source and destination Store source and destination

Unpack MWP case contents Unpack IUP case contents

Format for VDU display Format for VDU display

BAS Operations with Encryption

A-D

Process

Encrypt/Decrypt

Pack/Unpack

Wrap/Unwrap

Add/Read Tag

Send

NOP

IUP Operations with Encryption

A-D

Process

Encrypt/Decrypt

Pack/Unpack

Wrap/Unwrap

Add/Read Tag

Send

NOP

BAS - IUP Operations Comparison including EncryptionBAS (Multiple Data Protocols) IUP (Single IP-based Protocol)

XM SDA-D Conversion A-D ConversionPack in FBP case Pack in IUP caseEncrypt EncryptAdd FBP baggage tag Add IP baggage tagSend to FC Send to LR

FC LRRead FBP baggage tag Read IP baggage tagDecrypt NOPUnpack FBP case NOPRepack into BBP case NOPEncrypt NOPApply BBP baggage tag NOPSend to BC Send on to BR

BC BRRead BBP baggage tag Read IP baggage tagDecrypt NOPUnpack BBP case NOPRepack into MBP case NOPEncrypt NOPApply MBP baggage tag NOPSend to MC Send on to MR

MC MRRead MBP baggage tag Read IP baggage tagDecrypt NOPUnpack MBP case NOPRepack into OP case NOPEncrypt NOPApply OP baggage tag NOPSend to GW NOP

GW NOPRead OP baggage tag NOPWrap OP case inside IP case NOPApply IP baggage tag NOPSend to BCMS Send on to BCMS

BCMS BCMSRead IP baggage tag Copy IP case and baggage tag Read IP baggage tag Copy IUP case and IP baggage tagSend to CCMS Send to MW Send to CCMS Send to IUP OWS

MWUnwrap IP case NOPRead OP baggage tag NOPIdentify OP NOPDecrypt NOPUnpack OP case NOPRepack into MWP case NOPEncrypt NOPApply MWP baggage tag NOPSend to MW OWS NOP

MW OWS IUP OWSRead MWP baggage tag Read IP baggage tagStore source and destination Store source and destinationDecrypt DecryptUnpack MWP case contents Unpack IUP case contentsFormat for VDU display Format for VDU display

CCMS CCMSRead IP baggage tag Copy IP case and baggage tag Read IP baggage tag Copy IUP case and IP baggage tag

Send to MW Send to IUP OWSMW

Unwrap IP case NOPRead OP baggage tag NOPIdentify OP NOPDecrypt NOPUnpack OP case NOPRepack into MWP case NOPEncrypt NOPApply MWP baggage tag NOPSend to MW OWS NOP

MW OWS IUP OWSRead MWP baggage tag Read IP baggage tagStore source and destination Store source and destinationDecrypt DecryptUnpack MWP case contents Unpack IUP case contentsFormat for VDU display Format for VDU display