Recently, a friend asked me to explain fog computing. Is it different than cloud computing?
The term Cloud in an architectural diagram, as originally used, meant “it doesn’t matter where the computing is”, i.e., the term Cloud meant vague and undefined. As happens so often, a few big data center operators (you know their names) re-defined it to mean “in our far-away high-up location”. This definition supports their marketing but restricts the original purpose of the term.
Fog is taking back the cloud...
Read MoreServices
Architectural Principals of Transactive Energy
Transactive energy describes a pattern of integration where parties exchange the value or a commodity resource [power] over time and make forward commitments to sell or purchase that commodity. The Common Transactive Services (CTS) can be used in central auction-type systems, where a single entity announces or broadcasts prices or in markets were two or more parties come to a mutual agreement on price and delivery.
All forward transactions are committed, that is one party commits...
Independence of Services provided by Transactive Energy Nodes
Grid operators cannot know the purpose of each system attached to the grid. On a college campus, very similar sets of components: fans, ducts, temperature sensors, could provide environmental conditioning for a classroom whose windows can be opened, for office space, or for document archive which requires constant temperature and humidity. The most important attribute of animal quarters might be constant high-volume ventilation, while for a biohazard lab it might be maintaining a negative air pressure in the room. Humidity and temperature changes might make a basketball court slippery, and environmental management is focused on making sure that the All-American is not injured before the NCAA tournament.
Direct control for demand response requires that all parties know these issues and agree on their import. A central operator cannot know this.
Read MoreService Oriented Scheduling - Background Q&A
I received some very good feedback and questions on the first two parts of the Service Oriented Scheduling series (SOS). In particular, there were questions the relationship between EMIX and WS-Calendar, about the difficulty of creating Calendar artifacts, and about some elements that have been missing from traditional Calendar communications. In this post, I will try to address these.