The Last Big Thing

Developers of the Internet of Things always seems to be moving into the last big thing—at least as far as communications expectations and protocols. Too often security is an afterthought, something that can be bolted on afterward.

I often have to design secure communications for new deployments on a University campus. Many new roll-pits are still using RESTfull JSON. Remote systems often transfer telemetry to the cloud using unencrypted FTP. OpenADR generally uses reverse polling because corporate security won’t let external systems interact with on-premises systems secured with last generation security.

BACnet is moving closer to modern expectations with BACnet/SC. Control nodes and sensors can communicate using TLS-secured messages. Devices within the internal internet can work with certificates issued by the BACnet hub. Legacy systems can hide behind a BACnet hub and act AS IF they were secured.

Even so, older protocols and expectations sink in. BACnet router to BACnet application is still limited to Web Socket. ASHRAE specifies TLS 1.2 when many enterprises have moved to TLS 1.3. It is difficult to match the nimbleness of modern IT systems when putting in place systems that will not be replaced or re-programmed for a couple decades.

(Let me be clear here—my biggest complaint about BACnet SC is that I cannot yet deploy it. It is far more secure, and far better architected than what came before.)

Newer IT expectations are expected to continuously tune themselves based upon actual observed performance within their own environment. Applications that cannot do this on their own will end up sharing their data to cloud AI, with resulting loss of performance and loss of privacy and security. We all should know by now that data that goes to the cloud tends to get free in the cloud, offering the hacker or commercial competitor information for a decade. Once released, privacy never comes back.

Some IoT platform models have moved toward Docker. Docker provides a minimal Linux-like operating system (OS) to deploy code anywhere. I’m afraid that mainline IoT will get to Dockers just as the cloud moves to the next thing. On the edge, with the devices themselves, developer may wish to have multiple operating systems: one for Control, one for User Interface, one for AI. A Docker supporting Python for AI may require a lot of resources. Docker is and will remain to fat resource-demanding to support such applications on the edge.

I recently have seen some movement past Docker to DAPR (the Distributed Application Runtime). One can consider DAPR as a much lighter weight Docker. Different DAPR nodes are optimized for different languages. For example, there is a DAPR node pre-adapted to run the GO language (GOLANG or simply GO). GO is ideally suited to develop tiny replacements for Python AI routines. A GOLANG DAPR node can be much smaller and more efficient than is a Python routine on a Docker. Three DAPR nodes, one for control, one for AI based on GO, and one for UI based on .NET core can fit on a thermostat or other small system.

Upgrading some part of such a system, say upgrading the AI, could be as simple as swapping out the single DAPR node without touching the rest.

Don’t be slow to the last big thing. I recommend that smart building developers and smart energy developers consider what they might do with DAPR today.

The Right Time at the Right Place

Smart Energy uses schedule negotiation and schedule coordination to operate systems and equipment at the right time to take maximum advantage of variable energy supplies. As the internet of things grows up, it will move from gathering data from sensors to coordinating things to enhance our lives. The future of business breaks down into smaller entities with stronger missions that coordinate activities over time to support customers as if by a single business, only better. We all took steps closer to these seemingly simple coordination results, at a meeting at AOL headquarters.

For the last decade, the Calendaring and Scheduling Consortium (CalConnect) has worked to improve the interoperation of tools that coordinate schedules. We use their standards to run our personal and business lives, every time we accept a meeting request by email. Their work is critical to smart buildings and smart grids. This week, they demonstrated how to extend this work to support live machine to machine (M2M) schedule negotiations, including schedule auctions. My mind is buzzing with the implications.

Representatives of the US Veterans Administration (VA) were at CalConnect this week. The VA is in the news and under fire this week for failures related to scheduling and appointments. One can look to procedures and people and motivation, but under all is a cumbersome system that makes it difficult to accomplish some essential scheduling functions. These problems encourage employees to augment the system with a variety of out-of-system manual processes. These manual processes present opportunities both for mistakes and for gaming. Tragically, there was some of both.

VA management recognized the problems with scheduling systems well before the current scandals. It takes time to change anything so big. Last year, the VA held a competition to demonstrate standards-based approaches that could not only address the problems they have now, but can also prepare for more powerful stresses on their systems in the future. But knowing they had problems was not the same as knowing where and who the problems were. We have all found that out publicly in the last few weeks.

The story of the VA and open standards and how they hope to transform their monolithic systems in agile systems able to embrace outsourcing, insourcing, and distributed operations, is too long to fit here. I will write of it soon. I had the privilege of contributing to one of the competitors (my team came in third).  This week, the VA and those who hope to work with the VA were at CalConnect.  

CalConnect, now a decade old, ebbs and flows as does any organization. CalConnect was founded in a flurry of activity to address minimum capability cell phones, and worked through such problems as coordinating recurring meetings on a device too limited to compute once-a-week meetings. Today’s phones are more capable than personal computers then, and CalConnect has moved on to the problems of personal calendars in the age of social media. Calendar federation and social coordination bring new challenges.

Five years ago, CalConnect led the refresh of the aging standards for calendar information. iCalendar (RFC5545) is flexible and extensible, and describes key semantics and essential structure for everything you might see in your personal calendar. ITIP (RFC 5546) describes how to negotiate information between calendar-aware systems. You use it not only when you accept an email invitation, but also when that meeting is moved or cancelled.

Three years ago, CalConnect produced vAvailability, now moving to a standard in the IETF. (The Internet Engineering Task Force is the organization that manages the key specifications and communications of the internet.) . VAvailability is used in smart energy to advertise changing schedules for energy supply and for demand response. EMIX (Energy Market Information Exchange) defines contracts for Energy Reserves as financial options linked to vAvailability. OASIS developed WS-Calendar in close coordination with CalConnect.

But that is in the past. This week was exciting for the demonstration of new work that expands the tools for schedule coordination.

This week at CalConnect, multiple organizations demonstrated working interchanges of live schedule negotiations and schedule auctions. I will write more about the new standards such vPoll, CardDAV, and iSchedule later. The news is that this week CalConnect demonstrated three-server three-organization demonstration of standards-based schedule polling and auctions. The essential interactions for resource advertising and exchange were front and center. Direct server-to-server communications of schedules without the usual email were demonstrated, along with specific hooks for authorized interactions between web sites and personal calendars, and between trusted business partners.

Distributed schedule-based auctions are at the core of smart energy, including the budding efforts for interoperable transactive energy agents.

Standards-based scheduling engines will expand the reach and availability of specialized veteran’s services for today’s more mobile population. Open specifications for schedule negotiation can support more efficient and auditable queuing of complex scheduling requirements to be performed by multiple clinics. Distributed schedule-abased auctions will enable the VA to expand services and schedules to incorporate community resources far from the big VA Hospitals.

The next step of computer service is schedules for systems big and small to interact with our lives. The next step of business is improved provision of services across multiple businesses acting a single personal concierge, in medicine and in other personal services.

The tools for this were demonstrated at CalConnect this week. This work has powerful implications for smart energy, for medical scheduling, academic scheduling, and for social media. More later.

CalConnect invites interested organizations and companies to join CalConnect in moving the work
forward. www.calconnect.org

Smart Energy with a little bit of Seoul.

My visit to Seoul this month was fascinating. The country of Korea built its infrastructure essentially from scratch in the last 50 years, and in doing so was able to use modern technology to challenge some fundamental assumptions that we make in the USA. IP-based telephony predominates based on pervasive free Wi-Fi. Custom tailors use radical outsourcing mediated by IT to provide near-instant services. The National Virtual Power Plant (NVPP) is as up-to-date as any, while using big-data tools in ways not often seen here. There is a desire to embrace the new without fear that seems young and fresh in the way the US often does not. But somehow, the single observation that stays with me is how the use of IT to challenges our assumptions about natural monopolies.

The Seoul Metropolitan Subway system is by far the best I have been on. The signage is unusually good. Many stations have large interactive maps. Every car has digital signs that display the next station in multiple languages. Music plays on the platforms to warn of each impending arrival. In the winter, automatic seat warmers make even the ride itself pleasanter than expected.

The fare system is seamless. The system pioneered in Seoul is now used in many US systems: a card, a wave in, and a wave out, and a charge based on beginning and ending stations. The systems to add money to your fare card will tell you the remaining balance instantly, without inserting the card, or needing to punch buttons. Unlike in the US, every station has prominent stations on which to drop your card and get cash back. The $0.50 deposit on the card itself is just as easy to get back. There is even competition for these cards as three subway cards, one credit card, and several debit cards can be used interchangeably with your transit card. In short, it is customer focused, consumer friendly, and feels like anything but the bureaucratic experience it is in the US.

The high-tech experience extends into the amenities as well. Subways in the US are often dead zones. In Seoul, each line provides choices of digital connectivity: 4G, WiFi, DMB, and WiBro. This supports the widespread use of IP-telephony in Seoul; without the legacy commitment to lines, almost every smart phone uses the almost universal WiFi. (More on that later.)

All of this is supported by an easy to use App, one that puts the well-regarded BART App to shame. The free App, available for all the usual platforms, works out routes and provides station by station information with precise departure and arrival times. The cost for each route and stop is computed and displayed in advance. A potential rider always knows whether to rush, and when he will arrive.

In the US, this would all be delivered through a semi-private agency, a Transit Authority. In the Seoul, the nineteen subway lines are built and operated by ten separate companies. Some routes may have a higher cost per kilometer, or per station, but that information is readily available before your ride. Fares are automatically allocated to the different companies based on the same services that compute the entire fare. With appropriate use of IT, the multi-vendor service is provided as if through a single provider.

Regular readers may recognize that this is the model of Transactive Energy.

The Seoul Metropolitan Subway system tears down assumptions about how natural are our regulated natural monopolies. To someone who considers the smart grid, it stirs re-thinking of how we consider last mile distribution in a distributed energy world. Just as South Korean phones use the connectionless protocols of the internet to avoid considerable high-cost build out of telecommunications infrastructure, transactive energy and distributed energy can provide better service at lower costs.

To gain these advantages, we must embrace the distributed multi-supplier business models that enable them. Trust capitalism. Embrace minimal market design to limit friction when changing suppliers several times a day if desired. Use IT to smooth any bumps in transition. I’ve written about this in papers on microgrids and autonomous power nodes. It was nice to see it in the field.

BSI and a blast from the past

Every now and then I run across an old email that I have long forgotten, but speaks to my current activities. I think that this comment, written long ago in the oBIX forum speaks to something I need to return to. Jon recently gave me and WS-Calendar and EMIX some excellent advice on on creating standards for re-use and extension.

-----Original Message-----
From: Considine, Toby (Facilities Technology Office)
Sent: Wednesday, January 05, 2005 6:36 AM
To: 'jon.bosak@sun.com'
Cc: 'Grobler, Francois ERDC-CERL-IL'
Subject: RE: oBIX Guiding Principles

There are parts of Control Systems that are very business oriented. If an embedded control system detects that it needs maintenance, and can submit a maintenance request to an identified partner, clearly that work order looks like a normal business transaction.

Meeting and occupancy schedules might look like UBL (room will be occupied tomorrow from 2-4; use oBIX to inform HVAC, Access Control, Intrusion Detection, A/V management control systems. Read the Electric Meter before and after the meeting). Does the UBL standard extend the ICAL standard, or subsume it or...? Clearly, there is a benefit for scheduling functions to re-use commonly implemented scheduling requests.

These functions are in the future. What oBIX has to start with doing is exposing the event driven world of controls to the enterprise. For the most part, this starts with state. What are all the room temperatures on the 3rd and 4th floors? For how many hours did the compressors run today?Which areas of the building are currently secured? Some of this information is creeping into QOS agreements in real estate, and so intersects with the work of OSCRE (Open Systems for Commercial Real Estate). To my knowledge, UBL does not really include the nomenclatures for this because this is outside of the normal business functions. Am I wrong? Can you refer me to any relevant portions of UBL?

I think an early use for oBIX will be to provide a platform on which GRIDWISE (www.gridwise.org) type applications are built. That may be the first place where standard UBL functions hit, as price incentives are offered to buildings on the spot market to forefend brown-outs and the like. That feels more like bid/delivery/request rebate.

The construction industry has long had a separate open standard for construction documents, known as the IFC (Industry Foundation Classes) developed by the International Association for Interoperability (http://www.iai-international.org/iai_international/) and already required in many international construction projects. The IFC space includes construction documents, spatial data, spatial modeling, etc. The EU, in particular, leans heavily on this ISO specification, particularly in the Nordic countries. The largest landlord in the world, the GSA, has mandated that all transmittals for the design, construction, and acceptance of buildings. The closely related GBXML (Green Building XML) is a lightweight variant of IFCXML focused more on performance issues. GB Modeling, using GBXML for transferring building performance data, is required for those projects that wish to be designated as compliant with programs using words such as "sustainable" and "LEEDS". We have long considered that IFCML and the closely related GBXML were our most important shared spaces. Is there a defined interface/mapping between IFCXML and UBL?

Thanks for your comments

tc

-----Original Message-----
From: jon.bosak@sun.com
Sent: Tuesday, January 04, 2005 9:20 PM
To: Considine, Toby (Facilities Technology Office)
Subject: Re: oBIX Guiding Principles

| G) If, as seem likely, this document is adopted as an OASIS standard,
| I recommend that we steal freely from this document, reusing as much
| as we can in our rules for developing subsidiary oBIX services as well
| as in the core document. It is well written and defends its decison
| in a language that is focused and apropriate for the enterprise
| developer.

Since UBL is probably going to become the dominant standard for international trade documents, why don't you just adopt the UBL schemas and have done with it? After all, UBL is based on a pretty widely adopted specification (xCBL 3.0) that was developed specifically for electronic marketplaces. If there are any data elements missing from UBL 1.0 that are needed for oBIX, we can probably include them in UBL 1.1.

Jon