Energy Interoperation Common Transactive Services (CTS) Version 1.0

2 Energy Interoperation Common

3 Transactive Services (CTS) Version 1.0

4 Committee Specification Draft 01 5 Working draft 02

6 12 February 2021

7 This stage: 8 https://docs.oasis-open.org/energyinterop/ei-cts/v1.0/csd01/ei-cts-v1.0-wd02.pdf (Authoritative) 9 https://docs.oasis-open.org/energyinterop/ei-cts/v1.0/csd01/ei-cts-v1.0-wd02.html 10 https://docs.oasis-open.org/energyinterop/ei-cts/v1.0/csd01/ei-cts-v1.0-wd02.docx 11 Previous stage of Version 1.0: 12 https://docs.oasis-open.org/energyinterop/ei-cts/v1.0/csd01/ei-cts-v1.0-wd01.pdf (Authoritative) 13 https://docs.oasis-open.org/energyinterop/ei-cts/v1.0/csd01/ei-cts-v1.0-wd01.html 14 https://docs.oasis-open.org/energyinterop/ei-cts/v1.0/csd01/ei-cts-v1.0-wd01.docx 15 Latest stage of Version 1.0: 16 https://docs.oasis-open.org/energyinterop/ei-cts/v1.0/ei-cts-v1.0.pdf (Authoritative) 17 https://docs.oasis-open.org/energyinterop/ei-cts/v1.0/ei-cts-v1.0.html 18 https://docs.oasis-open.org/energyinterop/ei-cts/v1.0/ei-cts-v1.0.docx 19 Technical Committee: 20 OASIS Energy Interoperation TC 21 Chairs: 22 David Holmberg ([email protected]), NIST 23 William T. Cox ([email protected]), Individual 24 Editor: 25 Toby Considine ([email protected]), University of North Carolina at Chapel Hill 26 Additional artifacts: 27 This document is one component of a Work Product that also includes: 28 This prose specification is one component of a Work Product that also includes: 29  UML models 30  JSON schemas 31  Simple Binary Encoding binding (FIX) 32  XML schemas 33 Related work: 34 This document replaces or supersedes: 35  Common Transactive Services 1.0. The Energy Mashup Lab Specification. Edited by William T. Cox, 36 Toby Considine 30 November 2020. https://www.theenergymashuplab.org/s/cts-1-0-draft- 37 20201130.pdf 38 This document is related to:

ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 1 of 39 39  Energy Interoperation Version 1.0. Edited by Toby Considine, 11 June 2014. OASIS Standard. 40 http://docs.oasis-open.org/energyinterop/ei/v1.0/os/energyinterop-v1.0-os.html Latest version: 41 http://docs.oasis-open.org/energyinterop/ei/v1.0/energyinterop-v1.0.html. and its TeMIX Profile 42  OASIS Energy Market Information Exchange (EMIX) Version 1.0 Committee Specification 02 Edited 43 by Toby Considine, 11 January 2012. http://docs.oasis-open.org/emix/emix/v1.0/cs02/emix-v1.0- 44 cs02.html Latest version: http://docs.oasis-open.org/emix/emix/v1.0/emix-v1.0.html 45  OASIS WS-Calendar Platform-Independent Model version 1.0, Committee Specification 02 Edited by 46 William T. Cox and Toby Considine, 21 August 2015. http://docs.oasis-open.org/ws-calendar/ws- 47 calendar-pim/v1.0/cs02/ws-calendar-pim-v1.0-cs02.html Latest version: http://docs.oasis- 48 open.org/ws-calendar/ws-calendar-pim/v1.0/ws-calendar-pim-v1.0.html 49  OASIS WS-Calendar Schedule Signals and Streams Version 1.0 Committee Specification 01. Edited 50 by Toby Considine and William T. Cox, 18 September 2016. http://docs.oasis-open.org/ws- 51 calendar/streams/v1.0/cs01/streams-v1.0-cs01.html Latest version: http://docs.oasis-open.org/ws- 52 calendar/streams/v1.0/streams-v1.0.html 53 Declared XML namespaces: 54  list namespaces declared within this document (hyperlink if HTTP-based) 55 Abstract: 56 Common Transactive Services (CTS) allows actor interaction with any market. CTS is a streamlined and 57 simplified profile of the OASIS Energy Interoperation (EI) specification, which describes an information 58 and communication model to coordinate energy between any two Parties that consume or supply energy, 59 such as energy suppliers and customers, markets and service providers. 60 Status: 61 This document was last revised or approved by the OASIS Energy Interoperation TC on the above date. 62 The level of approval is also listed above. Check the "Latest stage" location noted above for possible later 63 revisions of this document. Any other numbered Versions and other technical work produced by the 64 Technical Committee (TC) are listed at https://www.oasis- 65 open.org/committees/tc_home.php?wg_abbrev=energyinterop#technical. 66 TC members should send comments on this document to the TC's email list. Others should send 67 comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send 68 A Comment" button on the TC's web page at https://www.oasis-open.org/committees/energyinterop/. 69 This document is provided under the RF on Limited Terms Mode of the OASIS IPR Policy, the mode 70 chosen when the Technical Committee was established. For information on whether any patents have 71 been disclosed that may be essential to implementing this document, and any offers of patent licensing 72 terms, please refer to the Intellectual Property Rights section of the TC's web page (https://www.oasis- 73 open.org/committees/energyinterop/ipr.php). 74 Note that any machine-readable content (Computer Language Definitions) declared Normative for this 75 Work Product is provided in separate plain text files. In the event of a discrepancy between any such 76 plain text file and display content in the Work Product's prose narrative document(s), the content in the 77 separate plain text file prevails. 78 Key words: 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 80 NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 81 be interpreted as described in BCP 14 [RFC2119] and [RFC8174] when, and only when, they appear in 82 all capitals, as shown here. 83 Alternative ISO key words description: 84 Within the normative text of this document, the terms "shall", "shall not", "should", "should not", "may", 85 "may not", "can", and "cannot" are to be interpreted as described in "Verbal forms for expressions of 86 provisions", Clause 7 of [ISO/IEC Directives]. 87 Citation format: 88 When referencing this document, the following citation format should be used: 89 [Energyinterop-CTS-v1.0]

ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 2 of 39 90 Energy Interoperation Common Transactive Services (CTS) Version 1.0. Edited by Toby Considine. 12 91 February 2021. OASIS Committee Specification Draft 01. https://docs.oasis-open.org/energyinterop/ei- 92 cts/v1.0/csd01/ei-cts-v1.0-csd01.html. Latest stage: https://docs.oasis-open.org/energyinterop/ei- 93 cts/v1.0/ei-cts-v1.0.html. 94 Notices: 95 Copyright © OASIS Open 2021. All Rights Reserved. 96 Distributed under the terms of the OASIS IPR Policy, [https://www.oasis-open.org/policies-guidelines/ipr]. 97 For complete copyright information please see the Notices section in the Appendix.

99 1 Introduction ...... 7 100 1.1 Generality of the Common Transactive Services ...... 8 101 1.2 Application of the Common Transactive Services ...... 8 102 1.3 The EML-CTS System ...... 8 103 1.4 Naming Conventions ...... 9 104 1.5 Editing Conventions ...... 9 105 1.6 Architecture ...... 9 106 1.6.1 Security Considerations ...... 9 107 1.6.2 CTS Extended Example ...... 9 108 2 Overview of Common Transactive Services ...... 11 109 2.1 Scope of Common Transactive Services ...... 11 110 2.2 Specific scope statements ...... 11 111 2.3 Terminology: Resources, Products and Instruments ...... 11 112 2.4 Assumptions ...... 12 113 2.4.1 Conformance with Energy Interoperation ...... 12 114 2.4.2 Conformance with EMIX ...... 12 115 2.4.3 Conformance with WS-Calendar Streams ...... 12 116 2.4.4 Compatibility with Facilities Smart Grid Information Model ...... 13 117 2.5 Common Transactive Services Architecture ...... 13 118 2.5.1 Sides in Tenders and Transactions ...... 14 119 2.5.2 Semantic Composition ...... 14 120 2.6 Products and Instruments ...... 15 121 3 Services and Operations ...... 17 122 3.1 Structure of Common Transactive Services and Operations ...... 17 123 3.2 Naming of Services and Operations ...... 17 124 3.3 Payloads and Messages ...... 17 125 3.4 Description of the Services and Operations ...... 17 126 3.5 Responses ...... 18 127 4 Transactive Services ...... 21 128 4.1 Pre-Transaction Services ...... 21 129 4.1.1 Interaction Pattern for the EiTender Service ...... 21 130 4.1.2 Information Model for the EiTender Services ...... 22 131 4.1.3 Operation Payloads for the EiTender Service ...... 24 132 4.2 Transaction Management Services ...... 25 133 . Interaction Pattern for the EiTransaction Service ...... 25 134 . Information Model for the EiTransaction Service...... 25 135 4.2.1 Operation Payloads for the EiTransaction Service ...... 26 136 4.3 Comparison of Transactive Payloads ...... 27 137 5 Market Information...... 28 138 5.1 The Market Context ...... 28 139 5.2 Interaction Pattern for the Market Context Service ...... 28 140 5.3 Information Model for the EiMarketContext Service ...... 28 141 5.4 Operation Payloads for the EiMarketContext Service ...... 29

ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 4 of 39 142 6 Bindings ...... 31 143 6.1 JSON ...... 31 144 6.2 XML Schema ...... 31 145 6.2.1 XML Namespaces ...... 31 146 6.3 Simple Binary Encoding ...... 31 147 7 Conformance ...... 32 148 7.1 Claiming Conformance to Common Transactive Services ...... 32 149 Appendix A. References ...... 33 150 A.1 Normative References ...... 33 151 A.2 Informative References ...... 34 152 Appendix B. Security and Privacy Considerations ...... 36 153 Appendix C. Acknowledgments ...... 37 154 C.1 Special Thanks ...... 37 155 C.2 Participants...... 37 156 Appendix D. Revision History...... 38 157 Notices ...... 39 158

159 1 Introduction 160 Common Transactive Services (CTS) allows actor interaction with any market. Technically, CTS is a 161 streamlined and simplified profile of the OASIS Energy Interoperation (EI) specification, which describes 162 an information and communication model to coordinate energy between any two parties, such as energy 163 suppliers and customers, markets and service providers. 164 Transactive Resource Management (TRM) has been used for many non-energy resources, such as water 165 delivery, network bandwidth, and even internet advertising. The initial research in TRM used a market to 166 allocate heat within a commercial building [TRM]. In TRM, a resource is defined as a tradable commodity 167 whose value depends on price, location, and time of delivery [EMIX]1. TRM balances supply and demand 168 over time using automated voluntary transactions between market participants. 169 TRM applied to energy is commonly referred to as Transactive Energy (TE). Neither EI nor CTS specifies 170 which technologies participants will use; rather they define a technology-agnostic interface to enable 171 accelerated market development of such technologies. 172 TRM is a means to allocate transactable energy resources including the delivery of commodities such as 173 electrical energy, electrical power, natural gas, and thermal energy such as steam, hot water, or chilled 174 water. Transactable energy resources also include the capability to deliver resources, such as 175 transmission line capacity and flow-rate capacity.2 176 The Common Transactive Services are a lightweight profile of the OASIS Energy Interoperation 177 specification. All CTS messages are simple and make no assumptions about the systems behind the 178 messages. 179 The target actors for CTS include but are not limited to 180  Smart Buildings/Homes/Industrial Facility 181  Building systems/devices 182  Business Enterprises 183  Vehicles 184  Microgrids 185  IoT (Internet of Things) devices 186 Transactive Energy has the potential to make our electrical system more efficient, by better matching 187 supply and demand in real time. TE enable actors to use energy when it is less expensive and produce 188 energy when it’s more valuable, thus reducing reliance on distant suppliers while maximizing use of local 189 power sources. TE relies on markets and consumer choice to make better decisions about power supply 190 and use. 191 TE demonstrations and deployments to date have been unique systems—each uses its own message 192 model and its own market dynamics. Many early implementations required the use of central or cloud- 193 based markets. Central markets discount local decision making while introducing new barriers to 194 resilience. Others rely on a single price-setting supplier. None are interoperable either at the system level 195 or for the actors involved. 196 Turning back to the more general Transactive Resource Management, nothing in CTS restricts its use to 197 electricity-based markets. Natural gas markets share many characteristics with electricity markets. Local 198 thermal energy distribution systems can balance electricity markets while having their own surpluses and 199 shortages. 200 Progress toward TE can be accelerated if a common interaction model is used across systems. Looked at 201 from another perspective, a client written for a participant in one such system should be able to

1 See http://docs.oasis-open.org/emix/emix/v1.0/cs02/emix-v1.0-cs02.html#_Toc319594576 2 In North American wholesale electricity markets, transmission rights are bought and sold.

ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 7 of 39 202 interoperate with another TE system. The Common Transactive Services from The Energy Mashup Lab 203 fulfil that promise.

204 1.1 Generality of the Common Transactive Services 205 CTS can be used to trade (Tender, Transact on) any [Transactive Resource]. While our focus is generally 206 on electrical energy or power, in the rest of this document we use [power] to mean electrical energy or 207 power or any other Transactive Resource. 208 The actual product in EML-CTS (next section) is implicit in the market with which one communicates. This 209 limits complexity of product definition to a useful level, so market and product definition may be 210 considered configuration rather than data.

211 1.2 Application of the Common Transactive Services 212 The purpose of this specification is to codify the common interactions and messages required for simple 213 markets, hence for simple transactive energy markets. Any system able to use CTS should be able to 214 interoperate with any CTS-conforming market with minimal or no change. 215 CTS defines communications between market actors and does not define the market or the device 216 controls. Autonomous market actors must be able to recognize patterns and make choices to best 217 support their own needs. Actors need not share details of their internal operations with others. 218 CTS is valuable for creating micromarkets to manage power within microgrids. Micromarkets support the 219 capability for dynamic restructuring of grids for fault resilience and efficiency [GridFaultResilience]. 220 Micromarkets contain complexity by abstracting interactions to the few common messages of CTS. 221 CTS does not presume a market with a single seller (e.g., a utility). CTS recognizes two parties to a 222 transaction, and the role of any party can switch from buyer to seller from one transaction to the next. 223 Each Resource Offer (Tender) has a Buy or Sell side attribute. We assume that when each transaction is 224 committed (once power has been purchased) it is owned by the purchaser, and it can be re-sold as 225 desired or needed. 226 A CTS-operated micromarket may balance power over time in a traditional distribution system attached to 227 a larger power grid or it may bind to and operate a stand-alone autonomous microgrid [BusinessCase].

228 1.3 The EML-CTS System 229 In 2015, the US National Institute for Standards and Technology (NIST) began the Transactive Energy 230 Modeling and Simulation Challenge (TE Challenge). A report delivered to TE Challenge in 2016 231 [CTS2016] defined a small subset of Energy Interoperation, known as the Common Transactive Services. 232 In 2019, The Energy Mashup Lab, under contract to NIST, began developing an open source software 233 system (Apache 2.0 license) that uses a robust financial or “order book” market for peer-to-peer 234 transactions. The system architecture separates market interactions from the actors buying and selling 235 power. The architecture also permits changing the market engine itself. This implementation is called 236 EML-CTS and is available today.3 237 In creating EML-CTS members of The Energy Mashup Lab further simplified CTS as a smaller subset 238 profile of the Energy Interoperation TeMIX profile [TEMIX]. 239 TE demonstrations have used different market engines, including double auction markets. EML-CTS was 240 designed to be able to use any (e.g. either, both, or some other market engine) while keeping interactions 241 between systems and the market unchanged. 242 The EML-CTS 1.0 implementation uses Java class definitions similar to those in the UML in this 243 specification. Messages are sent using REST POST operations, and JSON serialization uses the Java 244 classes.

3 https://github.com/EnergyMashupLab/eml-cts

ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 8 of 39 245 1.4 Naming Conventions 246 This specification follows some naming conventions for artifacts defined by the specification, as follows: 247 For the names of elements and the names of attributes within XSD files and UML models, the names 248 follow the lowerCamelCase convention, with all names starting with a lower-case letter. For example, 249 250 For the names of types within XSD files, the names follow the UpperCamelCase convention with all 251 names starting with a lower-case letter prefixed by “type-“. For example, 252 253 For clarity in UML models the suffix “type” is not always used. 254 For the names of intents, the names follow the lowerCamelCase convention, with all names starting with 255 a lower-case letter, EXCEPT for cases where the intent represents an established acronym, in which 256 case the entire name is in upper case. 257 JSON and where possible SBE names follow the same conventions.

258 1.5 Editing Conventions 259 For readability, element names in tables appear as separate words. The actual names are 260 lowerCamelCase, as specified above, and as they appear in the UML models, and in the XML and JSON 261 schemas. 262 All elements in the tables not marked as “optional” are mandatory. 263 Information in the Meaning column of the tables is normative. Information appearing in the Notes column 264 is explanatory and non-normative.4 265 Examples and Appendices are non-normative.

266 1.6 Architecture 267 Services requests and responses are public actions of each interoperating system. Service actions are 268 independent from private actions behind the interface (i.e., device control actions). A service is used 269 without needing to know all the details of its implementation. Services are generally paid for results, not 270 effort.

271 1.6.1 Security Considerations 272 Loose integration using the SOA style assumes careful definition of security requirements between 273 partners. Size of transactions, costs of failure to perform, confidentiality agreements, information 274 stewardship, and even changing regulatory requirements can require similar transactions be expressed 275 within quite different security contexts. It is a feature of the SOA approach that security is composed in to 276 meet the specific and evolving needs of different markets and transactions. Security implementation is 277 free to evolve over time and to support different needs. The Common Transactive Services allow for this 278 composition, without prescribing any particular security implementation.

279 1.6.2 CTS Extended Example 280 As an extended example, using the Common Transactive Services, a microgrid is comprised of a number 281 of interacting nodes (parties). Those parties interact in a micromarket co-extensive in scope with the 282 microgrid. No actor reveals any internal mechanisms, but only its interest in buying and selling power.

4 In ISO and IEC terminology, portions that are not normative are informative. OASIS uses the term non- normative instead.

ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 9 of 39 283 CTS can also be used for the fractal integration of microgrids. Any micromarket can be bound to or co- 284 extensive with a node in a larger microgrid. A micromarket participating in this way exposes only its 285 aggregate market position. Any participant in CTS effectively aggregates resources it logically contains. 286 In a similar way, in considering a topology of microgrids, any participant in the original micromarket MAY 287 itself represent a contained autonomous microgrid or, in fact, any autonomous entity whether or not it is 288 managed in turn by a market. [StructuredEnergy][SmartGridBusiness]

290 2.1 Scope of Common Transactive Services 291 CTS engages Transactive Resources, e.g. Distributed Energy Resources (DER) and any provider or 292 consumer of energy, while making no assumptions as to their processes or technology. 293 This specification supports agreements and transactional obligations, while offering flexibility of 294 implementation to support specific approaches and goals of the various participants. 295 No particular agreements are endorsed, proposed or required in order to implement this specification. 296 Energy market operations are beyond the scope of this specification although interactions that enable 297 management of the actual delivery and acceptance are within scope but not included in CTS 1.0.5 298 As shown in [CTS2016] the Common Transactive Services with suitable product definitions can be used 299 to communicate with essentially any market.

300 2.2 Specific scope statements 301 Interaction patterns and service definitions to support the following are in scope for Common Transactive 302 Services: 303  Interaction patterns to support transactive energy. 304  Information models for price and product communication. 305  Payload definitions for Common Transactive Services 306 The following are out of scope for Common Transactive Services: 307  Requirements specifying the type of agreement, contract, product definition, or tariff used by a 308 particular market. 309  Computations or agreements that describe how power is sold into or sold out of a market. 310 Section 5 describes standard bindings, which may be extended by The Energy Mashup Lab or others in 311 the future.

312 2.3 Terminology: Resources, Products and Instruments 313 Systems use the common transactive services to operate transactive resource markets. A transactive 314 resource market balances the supply of a resource over time and the demand for that resource by using a 315 market specifying the time of delivery. The seminal research in transactive resource management was 316 allocating the heat from a furnace within an office building at the Palo Alto Research Center (PARC). 317 Each register could bid for the heat based on how urgent was its need for heat. The key insight was that 318 markets could be built to allocate the heat and determine time of delivery. 319 A Resource is here defined as any commodity whose value is determined by time of delivery. 320 Transactable resources include, but are not limited to, heat, natural gas, water, and sewer as well as 321 energy. Transactive energy considers energy or power as resources. The services that support energy 322 delivery such as transport and congestion fees are also considered transactable energy resources. The 323 ancillary services reactive power, voltage control, and frequency control are transactable. Even network 324 bandwidth has been managed as a transactable resource. 325 A Product names a transactive resource that has been “chunked” for market. These chunks define the 326 market granularity in quantity and in time. Transactable energy, for example, could be in either Joules or 327 Watts. Products as defined in EMIX have a scale factor as well. An Energy Product can be denominated

5 See e.g. Energy Interoperation EiDelivery Service https://docs.oasis- open.org/energyinterop/ei/v1.0/os/energyinterop-v1.0-os.html#_Toc388604056

ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 11 of 39 328 in be in megajoules or in kilowatts. An actor intending to buy or sell needs to know what is bought or sold 329 in this market. 330 Temporal granularity is as important for product definition as is quantity. One-hour markets are common 331 in many markets, that is the energy delivered over the duration of an hour. Common transactive energy 332 markets in North America today have durations as brief as two seconds. 333 A system that intends to buy or sell energy products must know what products are traded in the local 334 market. 335 An instrument is a product at a specific time, say, several units of the 10 kW for an hour product 336 purchased for delivery at 3:00 PM. We follow financial markets in calling an item that is bought or sold an 337 instrument. The market considers all the tenders to buy or sell an instrument to match prices. The trading 338 for the instrument for this product at 3:00 PM is separate from the trading for the similar instrument for the 339 same product at 4:00 pm. 340 The OASIS specification Energy Market Information Exchange [EMIX] defines a semantic mechanism for 341 describing products that can then be traded at specific times. In particular, EMIX defines Items (resource 342 and granularity) for power, energy, transport, and ancillary services and uses Duration as defined in [WS- 343 Calendar] to define temporal granularity. We re-group these EMIX terms into Resources and Products for 344 simple reference in simple markets. 345 The EMIX Item is extensible so additional conforming Resources may be defined. Those Resources can 346 be used to define conforming Products. Those Products can be traded in transactive resource markets 347 based on this specification.

348 2.4 Assumptions

349 2.4.1 Conformance with Energy Interoperation 350 OASIS Energy Interoperation [EnergyInterop] Transactive Services is the basis for CTS, which draws 351 definitions of actors, parties, and transactive interactions from the Energy Interoperation TEMIX profile. 352 Energy Interop assumes an Energy Services Interface (ESI) as the external face of the energy- 353 consuming or supplying node. Energy Interop defines an end-to-end interaction model; this characteristic 354 is shared by CTS.

355 2.4.2 Conformance with EMIX 356 This specification uses models and artifacts simplified from and in the style of OASIS Energy Market 357 Information Exchange [EMIX] to communicate product definitions, quantities, and prices. EMIX provides a 358 succinct way to indicate how prices, quantities, or both vary over time. 359 The EMIX product definition, as included in the Transactive Resource, is implied in CTS 1.0. Future CTS 360 specifications may include market context from EMIX and Energy Interop, as well as other information on 361 products and markets including market terms.

362 2.4.3 Conformance with WS-Calendar Streams 363 The WS-Calendar specifications6 express sequences and enable negotiation of schedules in a manner 364 that is semantically compatible with human schedules, i.e., [iCalendar]. The WS-Calendar Platform 365 Independent Model (PIM) [WsCalendar-PIM] defines common semantics for the specifications. WS- 366 Calendar is the standard under the NIST Smart Grid Roadmap for all such communication. 367 WS-Calendar is used to describe products whose value changes with time of delivery, and again into 368 Energy Interoperation, which uses Transactive Resources.

6 See Section A.1 Normative References

ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 12 of 39 369 This specification bases its representation of single intervals on Schedule Signals and Streams [Streams], 370 a WS-Calendar-PIM conforming specification for expressing consecutive occurrences of schedules or 371 products. 372 A current implementation, EML-CTS, transacts a single interval at a time expressed as a single-interval 373 Stream. Energy systems supported by CTS-based markets may express their requirements and 374 capabilities over time using multi-interval Streams or in separate single-interval Streams.

375 2.4.4 Compatibility with Facilities Smart Grid Information Model 376 The Facilities Smart Grid Information Model [FSGIM] was developed to define the power capabilities and 377 requirements of building systems over time. FSGIM addresses the so-called built environment and uses 378 the semantics of WS-Calendar and EMIX to construct its information models for [power] use over time. 379 These sequences of [power] requirements are referred to as load curves. Load curves can potentially be 380 relocated in time, perhaps delaying or accelerating the start time to get a more advantageous price for 381 [power]. These load curves are the basis upon which a TE Agent would base its market decisions. 382 The Architecture of EML-CTS is premised on distinct physical systems being able to interoperate by 383 coordinating their production and consumption of [power]7 irrespective of their ownership, motivations, or 384 internal mechanisms. This specification defines messages and interactions of that interoperation. 385 CTS tenders and transactions can be used to express FSGIM load requests. CTS 1.0 uses single- 386 interval Streams to express single-interval tenders in anticipation of the possible use of Streams in 387 FSGIM-conformant communications.8

388 2.5 Common Transactive Services Architecture 389 The implied CTS architecture is drawn from and is a subset and simplification of the architecture 390 presented in [EnergyInterop]. Specifically, the Energy Interoperation architecture uses the Service- 391 Oriented Architecture (SOA) model which has become the consensus view for energy-related 392 interoperation. 393 The Energy Mashup Lab uses the Actor Model, which can be implemented in SOA with a few lightweight 394 Service Operations. The Lab adapted the SOA model of Energy Interoperation into an Actor-to-Actor 395 model that requires fewer and lighter weight messages. 396 The Actor Model names a style of system integration used for high scalability and resilience.9 The Actor 397 Model uses a small number of simple messages to coordinate behavior among simple agents termed 398 Actors. Note that Actors need not be actually simple; any complexity in the Actors are reduced to simple 399 messages. 400 Simple messages are an essential aspect of actor architectures. The Common Transactive Services are a 401 lightweight profile of the OASIS Energy Interoperation specification, and in fact of the TEMIX profile of 402 Energy Interoperation. All CTS messages are simple and make no assumptions about the systems 403 behind the messages. 404 Just as the market participants present simple messages, so too, does the market. The internals of a 405 market contain a market engine to match tenders and to declare contracts. The rules used to match 406 tenders could be nearly instant order book, or periodic double auction, or some other model. This 407 complexity is hidden. The market receives tenders and announces contracts. Only the simple messages 408 of CTS are used.

7 See Section 1.1. 8 Conformance with the Energy Interoperation TEMIX Profile may require single intervals. 9 See C. Hewitt, "Actor Model of Computation: Scalable Robust Information Systems," arxiv.org, 2010, or C. Hewitt, "A Universal Modular Actor Formalism for Artificial Intelligence," ICJA, 1973, or many other references

ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 13 of 39 409 All interactions described in CTS are as defined in [EnergyInterop]. That specification describes 410 interactions between pairs of actors, and, in a deployment, relationships are established among actors. 411 Actors may perform in pairwise chains of actors. 412 All interactions and actors below are described as if for Actors in electrical energy markets. For use in 413 other transactive energy markets, or even transactive resource markets, only the product or resources 414 would be changed. 415 An actor takes on a role, for example a business role as a Party. In the UML model, PartyId and 416 CounterPartyId inherit from ActorId which in turn inherits from class UidType.

417 2.5.1 Sides in Tenders and Transactions 418 At any moment, a Party has a position which represents the cumulative amount of power (or other 419 product) that an actor has previously transacted for that time interval. 420 A Party can take one of two Sides in a given Transaction: 421  Buy, or 422  Sell 423 A Party selling [power] relative to its current position takes the Sell Side of the Transaction. A Party 424 buying [power] relative to its current position takes the Buy Side of the Transaction. 425 From the perspective of the market, there is no distinction between a party selling additional power and 426 party selling from its previously acquired position. An Actor representing a generator generally takes the 427 Sell side of a transaction. An Actor representing a consumer generally takes the Buy side of a 428 transaction. A generator may take the Buy Side of a Transaction in order to reduce its own generation, in 429 response either to changes in physical or market conditions or to reflect other commitments made by the 430 actor. A consumer may choose to sell from its current position if its plans change, or if it receives an 431 attractive price. A power storage system actor may choose to buy or sell from interval to interval, 432 consistent with its operating and financial goals. 433 We do not specify how the [power] is delivered. For example, a long-distance transfer might be 434 implemented with the seller selling power to its local grid and the buyer buying power from its local grid, 435 with financial reconciliation producing the same result as a direct sale and deliver.

436 2.5.2 Semantic Composition 437 The semantics and interactions of CTS are selected from and derived from [EnergyInterop]. 438 Energy Interoperation incorporates two other standards, [EMIX] and [WS-Calendar], and uses an early 439 Streams definition. 440  EMIX describes price and product for electricity markets. 441  WS-Calendar communicates schedules and sequences of operations. This specification uses the 442 [Streams] optimization which is a standalone specification, rather than part of Energy 443 Interoperation 1.0. 444  Energy Interoperation uses the vocabulary and information models defined by those 445 specifications to describe the services that it provides. The payload for each Energy 446 Interoperation service references a product defined using [EMIX]. EMIX schedules and 447 sequences are defined using [WS-Calendar]. Any additional schedule-related information 448 required by [EnergyInterop] is expressed using [WS-Calendar]. 449  Since [EnergyInterop] was published, a semantically equivalent but simpler [Streams] 450 specification was developed in the OASIS WS-Calendar Technical Committee10. CTS uses that 451 simpler [Streams] specification.

10 https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-calendar

ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 14 of 39 452 In effect, CTS is a profile of Energy Interoperation but with simplified information models and defines only 453 payloads, not the messaging. 454 CTS 1.0 supports a market for a single product (say energy) in multiple time intervals. 455 Product definition in CTS 1.0 are implicit but characteristics can be discerned using the market context 456 requests and responses. 457 Future development of CTS is planned to include discoverable market and product description 458 information through the EMIX and Energy Interoperation Market Context. The EMIX Market Context 459 associates market rules and catalogs the products tradeable. 460 Future versions of CTS will support multiple markets and multiple products. 461 All terms used in this specification are as defined in their respective specifications.

462 2.6 Products and Instruments 463 An EMIX product is a specific resource. To transact that product, it is packaged in a tender with a specific 464 quantity for a specific duration. 465 CTS transacts power products at specific times. The thing traded (often called an instrument in financial 466 markets) includes the product together with quantity and the time interval. Tenders become contracts 467 when a tender to buy some quantity of a product are matched with a tender to sell the same quantity of 468 that product.11

11 Most underlying matching engines and markets trade instruments, which are associated with a product definition —which may not be fully expressed in an EMIX product definition—plus quantity and time.

469 3 Services and Operations 470 This section re-iterates terms and simpler models from [EnergyInterop]. That specification is normative. 471 This terminology is used through all payload definitions presented in this specification. 472 The column labeled Response lists the name of the service operation payload (in Energy Interoperation 473 and its TEMIX profile, this includes the service operation as well) invoked in response. Most operations 474 have a response. The roles of Service Consumer and Service Provider are reversed for the Response. 475 For transactive services any party may receive tenders (priced offers) of service and possibly make 476 tenders (priced offers) of service. 477 Any party using transactive energy services may own generation or distributed generation or reduce or 478 increase energy from previously transacted energy amounts. The dispatch of these resources and the 479 use of energy by a party are influenced by tenders between Parties that may result in new Transactions 480 and changes in operations.

481 3.1 Structure of Common Transactive Services and Operations 482 The Common Transactive Services presented in this specification are only 483  Transactive Services—for implementing transactions and tenders 484 We include UML definitions for the standard payloads for service requests, rather than the service, 485 communication, or other characteristics. In Section 6 we describe standard serialization for the CTS 486 standard payloads; additional bindings may be used by conforming implementations.

487 3.2 Naming of Services and Operations 488 The naming of services and operations follows a pattern defined in . Services are named starting with the 489 letters Ei following the Upper Camel Case convention. Operations in each service use one or more of the 490 following patterns. The first listed is a fragment of the name of the initial service operation; the second is a 491 fragment of the name of the response message which acknowledges receipt, describes errors, and may 492 pass information back to the invoker of the first operation. 493 Create—Created An object is created and sent to the other Party 494 Cancel—Canceled A previously created request is canceled 495 For example, to construct an operation name for the EiTender service, "Ei" is concatenated with the name 496 fragment (verb) as listed. An operation to cancel an outstanding Tender is called EiCancelTender.12

497 3.3 Payloads and Messages 498 We define only the payloads; the particular networking technique and message structure is determined by 499 the applications sending and receiving CTS payloads.

500 3.4 Description of the Services and Operations 501 The sections below provide the following for each service: 502  Service description

12 This pattern was developed and is used by current work in the IEC Technical Committee 57 (Power Systems).

ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 17 of 39 503  Table of operations 504  Interaction patterns for the service operations in graphic form, using Energy Interoperation 505 normative interactions 506  Normative information model using [UML] for key artifacts used by the service 507  Normative operation payloads using [UML] for each operation

508 3.5 Responses 509 In a service interaction, responses may need to be tracked to determine if the transaction is successful or 510 not. This may be complicated by the fact that any given transaction may involve the transmission of one 511 or more information objects. 512 An EiResponse returns the success or failure of the entire operation, with possible detail included in 513 responseTermsViolated (not in this release).. 514 It is MANDATORY to return as appropriate both errors and success in responses.13 515 The class diagram in Figure 3-1 reflects the generic response in CTS 1.0. 516 The description of EiResponseType is from Energy Interoperation, changing only the cardinality of 517 responseDescription (to zero, that is, not passed).

518 519 Figure 3-1: Example of generic error response for a service operation 520 The attributes of EiResponseType are in the following table.

13 This contrasts with Energy Interoperation, where it is not mandatory to return any responses if the entire EiCancelTender service operation was completed successfully. The pattern in Energy Interoperation is to return those that have failed (required) and those that succeeded (optional).

Attribute Meaning Notes

Created DateTime Optional timestamp indicating the date and time when this EiResponse was created

Request ID A reference ID which identifies the artifact Provided by the payload generation or message element to which this is a and/or messaging system. response. The Request ID uniquely identifies this request, and can serve as a messaging correlation ID14.

Response Code The Response Code indicates success or EML-CTS uses response code 200 failure of the operation requested. The for success Response Description is unconstrained text, perhaps for use in a user interface. The code ranges are those used for HTTP response codes,15 specifically 1xx: Informational - Request received, continuing process 2xx: Success - The action was successfully received, understood, and accepted 3xx: Pending - Further action must be taken in order to complete the request 4xx: Requester Error - The request contains bad syntax or cannot be fulfilled 5xx: Responder Error - The responder failed to fulfill an apparently valid request

Response Description The Response Description is in the model Not present in CTS 1.0 payloads but profiled to be cardinality 0..0.

Response Terms Violated The Terms Violated by the request to Market Terms and Market Context which this is a response. Conforming CTS may be implemented in a future 1.0 implementations SHALL omit this release. Work is in progress to attribute. profile and simplify the terms.

522 523 There is no exhaustive list of all possible Response Codes. The Response Codes are intended to enable 524 even the smallest device to interpret Response. This specification uses a pattern consisting of a 3-digit 525 code, with the most significant digit sufficient to interpret success or failure. This pattern is intended to 526 support that smallest device, while still supporting more nuanced messages that may be developed. 527 While the only value after the leading digit the Response Code defined in Energy Interoperation is 00, 528 conforming specifications may extend these codes to define more fine-grained response codes. These 529 should extend the pattern above; for example, a response code of 403 should always be within the realm 530 of Requester Error. 531 EML-CTS uses response code 200 for success.

14 As an example of the Correlation Pattern for messages 15 See e.g. https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

532 4 Transactive Services 533 Transactive Services define and support the lifecycle of transactions from initial Tender to final 534 settlement. The phases described in [EnergyInterop] are 535  Registration—to enable further phases. (Not part of CTS) 536  Pre-Transaction —binding tenders for transactions. (Part of CTS) 537  Transaction Services—execution and management of transactions. (Part of CTS) 538  Post-Transaction—settlement, energy used or demanded, payment, position. (Not part of CTS) 539 For transactive services, the roles are Parties and Counterparties. 540 The terminology of this section is that of business agreements: tenders and transaction. The Service 541 descriptions and payloads are simplified and updated from those defined in Energy Interoperation.

542 4.1 Pre-Transaction Services 543 Pre-transaction services are those between parties that may prepare for a transaction. The pre- 544 transaction services in CTS is EiTender with payloads shown in Table 4-1. 545 Tenders and transactions are artifacts based on [EMIX] artifacts suitably flattened and simplified, and 546 which contain schedules and prices in varying degrees of specificity or concreteness. 547 Table 4-1: Pre-Transaction Tender Services

Service Request Payload Response Payload Notes

EiTender EiCreateTenderType EiCreatedTenderType Create and send Tender

EiTender EiCancelTenderType EiCanceledTenderType Cancel one or more Tenders

EiTender EiDistributeTenderType None Distribute a list of Tenders to a transport or messaging system defined list of parties

548

549 4.1.1 Interaction Pattern for the EiTender Service 550 Figure 4-1 presents the [UML] sequence diagram for the EiTender Service. Note that EiDistributeTender 551 is not part of CTS 1.0, but is being considered for a future release.

554 4.1.2 Information Model for the EiTender Services 555 The information model for the EiTender Service artifacts follows that of [EMIX], but flattened and with 556 product definition implied by the implementation. 557 Time interval, price, and quantity are key elements for a product; the other aspects of product definition 558 (e.g. energy and units) are implicit as described in Section 2.5.2.

559 560 Figure 4-2: Class EiTenderType 561 The attributes of EiTender are shown in the following table.

Attribute Meaning Notes

Expiration Time The date and time after which this Tender is no longer valid.

Integral Only All of the Tender must be bought or sold In CTS set to False. Partial sale or at once; no partial sale or purchase purchase is always allowed. The attribute is present for possible future evolution.

Interval The time interval for the product being offered

Price The unit price for the product being Total price is the product of price offered and quantity

Quantity The quantity of the product being offered Total price is the product of price and quantity

Side Whether the tender is to buy or to sell the product

Tender ID An ID for this tender

Transactive State The transactive state of this payload See below (tender)

563 564 Transactive State is a concept from EMIX; it describes the state of an object. For CTS 1.0, only states 565 tender and transaction are used.

566 567 Figure 3-3 Enumeration TransactiveStateType

ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 23 of 39 568 4.1.3 Operation Payloads for the EiTender Service 569 The [UML] class diagram describes the payloads for the EiTender service operations.

570 571 Figure 4-4: UML Class Diagram for the Operation Payloads for the EiTender Service

ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 24 of 39 572 4.2 Transaction Management Services 573 This section presents the Transaction Service payloads. 574 market context and product are implied and may in the future be made explicit with a Market Context 575 reference (see Section 2.5.2). Canceling or modifying transactions is not permitted in either CTS or 576 Energy Interoperation. Following the approach in distributed agreement protocols16, compensating 577 tenders and transactions SHOULD be created as needed to compensate for any effects.17 578 Table 4-3: Transaction Management Service

Service Request Response Notes

EiTransaction EiCreateTransactionType EiCreatedTransactionType Create and send Transaction

579 . Interaction Pattern for the EiTransaction Service 580 This is the [UML] sequence diagram for the EiTransaction Service:

581 582 Figure 4-5: UML Sequence Diagram for the EiTransaction Service

583 . Information Model for the EiTransaction Service 584 Transactions are derived from [EMIX] artifacts including a Stream with time, quantity, and price. 585 Flattening similar to that in EiTender is used. 586 Although an EiTransaction object includes the original EiTender, the EiTransaction carries its own 587 Transactive State.

16 See, e.g., WS-Transaction and WS-BusinessActivity. 17 This is consistent with the way that distributed agreement protocols such as [WS-BusinessActivity] manage compensation rather than cancelation.

ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 25 of 39 588 589 Figure 4-6: UML Class Diagram of EiTransaction 590 The attributes of EiTransaction are shown in the following table. 591 Table 4-4: EiTransaction Attributes

Attribute Meaning Notes

Tender The tender (Fig. 4-2) that led to this The ID, quantity and price may Transaction. differ from that originally tendered due to market actions.

Transaction ID An ID for this Transaction The contained Tender has its own TenderID

Transactive State The transactive state of this payload is See Figure 3-3 Enumeration transaction TransactiveStateType

592

593 4.2.1 Operation Payloads for the EiTransaction Service 594 The [UML] class diagram describes the payloads for the EiTransaction service operations.

595 596 Figure 4-7: UML Class Diagram of EiTransaction Service Operation Payloads

ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 26 of 39 597 4.3 Comparison of Transactive Payloads 598 599 Figure 4-8: UML Diagram comparing all Transactive Payloads

600

ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 27 of 39 601 5 Market Information 602 Each Event and Service in Energy Interoperation takes place within a Market Context. This Context 603 defines the behaviors that that each Party can expect from the other. 604 This concept with some simplification is part of the Common Transactive Services. 605 This is work in progress.

606 5.1 The Market Context 607 Market Contexts are resolvable URIs and are used to express market information that rarely changes, so 608 it is not necessary to communicate it with each message. 609 In any market context, there are standing terms and expectations about product offerings. If these 610 standing terms and expectations are not known, many exchanges may need to occur before finding 611 products that meet those expectations. If these expectations are only known through local knowledge, 612 then national and international products need to be re-configured for each local market that they enter. If 613 all market information were to be transmitted in every information exchange, messages based on EMIX 614 would be overly repetitive. 615 The Market Context for CTS is simplified from that in Energy Interoperation.

616 5.2 Interaction Pattern for the Market Context Service 617 The Market Context Service enables a Party to request the details of a Market Context. Parties MAY be 618 able to request and compare Market Contexts to select which markets to participate in. Such Interactions 619 are out of scope for this specification.

620 621 Figure 5-1: UML Sequence diagram for Market Context service 622 The Market Context service can retrieve the full information associated with an EiMarketContext. There is 623 one operation and a responding operation. 624 Profiled and simplified market context information is planned for a future release.

625 5.3 Information Model for the EiMarketContext Service 626 Simplified profile pending.

628 629 Figure 5-2: UML of Market Context Service payloads

630 6 Bindings 631 Payloads and interaction patterns are described in [UML] in Section  above. This section contains 632 bindings for the payloads in three encoding schemes: 633  JSON [JSON] 634  XML Schema [XSD] 635  FIX Simple Binary Encoding [SBE]

636 6.1 JSON 637 TODO—JSON Schema available

638 6.2 XML Schema 639 TODO—XML Schema available

640 6.2.1 XML Namespaces

641 6.3 Simple Binary Encoding 642 TODO—Work in progress

ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 31 of 39 7 Conformance (Note: The OASIS TC Process requires that a specification approved by the TC for public review, or for publication at the Committee Specification or OASIS Standard level must include a separate section, listing a set of numbered conformance clauses, to which any implementation of the specification must adhere in order to claim conformance to the specification (or any optional portion thereof). This is done by listing the conformance clauses here. For the definition of "conformance clause," see OASIS Defined Terms. See "Guidelines to Writing Conformance Clauses": https://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html. Remove this note before submitting for publication.) By design, CTS is a simplified and restricted subset profile of TeMIX. CTS simplifies aspects of OASIS Energy Interoperation, and omits other aspects. This section informally describes how CTS relates to the TeMIX profile. CTS is a profile of the TeMIX Profile of Energy Interoperation 1.0, described in Section 14.2 of [EnergyInterop] with the following changes: 1. Only the Payloads for Service Operation and the interaction patterns are defined. 2. The following Services from the TeMIX profile are omitted: a. EiRegisterParty b. EiQuote c. EiEnroll d. EiDelivery 3. The following Services from the TeMIX profile are included and simplified as follows. a. Attribute names have been made consistent with lowerCamelCase conventions. b. The inheritance hierarchy for UIDs and identifier types have been simplified i. Only selected identifier types are included ii. The identifier types in this draft specification are opaque types rather than strings c. The enumeration TransactiveStateType is identical to that in Energy Interoperation, but only the following Transactive States are used: i. Tender ii. Transaction iii. Indication of Interest (pending work in progress) d. Market Context and the EMIX Market Context are flattened and simplified as follows: i. MarketContextType is a URI. ii. Standard Terms are not profiled in this draft, but are planned to be a flattened and simplified subset of the EMIX Standard Terms. Portions of CTS conform to and use updated and simplified versions of the specifications consumed by Energy Interoperation, specifically  OASIS WS-Calendar [MIN]  OASIS WS-Calendar Schedule Streams and signals [Streams] This draft specification uses the WS-Calendar [MIN] interval directly (as IntervalType). An update in progress will instead use WS-Calendar Schedule Streams and Signals [Streams] with single interval streams. This will permit future implementations to use streams of values where appropriate..

7.1 Claiming Conformance to Common Transactive Services This section will describe conformance clauses for implementations claiming conformance to Common Transactive Services.

This appendix contains the normative and informative references that are used in this document. Normative references are specific (identified by date of publication and/or edition number or Version number) and Informative references may be either specific or non-specific. While any hyperlinks included in this appendix were valid at the time of publication, OASIS cannot guarantee their long-term validity.

Note: Any normative work cited in the body of the text as needed to implement the work product must be listed in the Normative References section below. Each reference to a separate document or artifact in this work must be listed here and must be identified as either a Normative or an Informative Reference.

For all References – Normative and Informative: Recommended approach: Set up [Reference] label elements as "Bookmarks", then create hyperlinks to them within the document at locations from which the references are cited. Citations in the body of the text should be hyperlinked to the appropriate Reference entry, not directly to targets which are not a part of this Work Product.

The proper format for citation of technical work produced by an OASIS TC (whether Standards Track or Non-Standards Track) is:

[Citation Label] Work Product title (italicized). Edited by Albert Alston, Bob Ballston, and Calvin Carlson. Approval date (DD Month YYYY). OASIS Stage Identifier and Revision Number (e.g., OASIS Committee Specification Draft 01). Principal URI (stage-specific URI, e.g., with stage component: somespec-v1.0-csd01.html). Latest stage: (static URI, without stage identifiers, used as a symbolic link to most recently published stage of this Version).

For example:

[OpenDoc-1.2] Open Document Format for Office Applications (OpenDocument) Version 1.2. Edited by Patrick Durusau and Michael Brauer. 19 January 2011. OASIS Committee Specification Draft 07. https://docs.oasis- open.org/office/v1.2/csd07/OpenDocument-v1.2-csd07.html. Latest stage: https://docs.oasis- open.org/office/v1.2/OpenDocument-v1.2.html.

Reference sources: For references to IETF RFCs, use the approved citation formats at: https://docs.oasis-open.org/templates/ietf-rfc-list/ietf-rfc-list.html. For references to W3C Recommendations, use the approved citation formats at: https://docs.oasis-open.org/templates/w3c-recommendations-list/w3c-recommendations-list.html. Remove this note before submitting for publication.

A.1 Normative References The following documents are referenced in such a way that some or all of their content constitutes requirements of this document.

[RFC8174] ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 33 of 39 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [ISO/IEC Directives] (Only used if ISO/IEC Key words are elected in front pages) ISO/IEC Directives, Part 2 (Eighth edition) Principles and rules for the structure and drafting of ISO and IEC documents, International Organization for Standardization and International Electrotechnical Commission, 2018. https://www.iso.org/sites/directives/current/part2/index.xhtml. [EMIX] Energy Market Information Exchange (EMIX) Version 1.0, January 2012, OASIS Committee Specification 02, Latest version: http://docs.oasis-open.org/emix/emix/v1.0/emix-v1.0.html. [EnergyInterop] Energy Interoperation Version 1.0. Edited by Toby Considine. 11 June 2014. OASIS Standard. http://docs.oasis-open.org/energyinterop/ei/v1.0/energyinterop-v1.0.html. [JSON] JavaScript Object Notation and JSON Schema. https://cswr.github.io/JsonSchema/ [RFC2119] (Only used if RFC Key words are elected in front pages) Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2246] T. Dierks, C. Allen Transport Layer Security (TLS) Protocol Version 1.0, http://www.ietf.org/rfc/rfc2246.txt, IETF RFC 2246, January 1999. [SBE] Simple Binary Encoding Technical Specification 1.0. FIX Trading Community, June 16, 2016. https://www.fixtrading.org/standards/sbe/ [WS-Calendar-PIM] WS-Calendar Platform Independent Model (PIM) Version 1.0. Edited by William Cox and Toby Considine. 21 August 2015. OASIS Committee Specification. Error! Hyperlink reference not valid.http://docs.oasis-open.org/ws-calendar/ws-calendar-pim/v1.0/ws-calendar-pim-v1.0.html. [MIN] WS-Calendar Minimal PIM-Conformant Schema Version 1.0. Edited by William Cox and Toby Considine. 26 August 2016. OASIS Committee Specification. http://docs.oasis-open.org/ws-calendar/ws-calendar- min/v1.0/ws-calendar-min-v1.0.html . [Streams] Schedule Signals and Streams Version 1.0. Edited by Toby Considine and William T. Cox. 18 September 2016. OASIS Committee Specification. http://docs.oasis-open.org/ws-calendar/streams/v1.0/streams- v1.0.html. [XSD] W3C XML Schema Definition Language (XSD) 1.1. Part 1: Structures, S Gao, C. M. Sperberg-McQueen, H Thompson, N Mendelsohn, D Beech, M Maloney http://www.w3.org/TR/xmlschema11-1/, April 2012, Part 2: Datatypes, D Peterson, S Gao, A Malhotra, C. M. Sperberg-McQueen, H Thompson, P Biron, http://www.w3.org/TR/xmlschema11-2/ April 2012

A.2 Informative References The following referenced documents are not required for the application of this document but may assist the reader with regard to a particular subject area.

[RFC3552] ei-cts-v1.0-wd02 3 March 2021 Standards Track Work Product Copyright © OASIS Open 2021. All Rights Reserved. Page 34 of 39 Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [Actors] C. Hewitt, "Actor Model of Computation: Scalable Robust Information Systems," arxiv.org, 2010. [Framework] National Institute of Standards and Technology, NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0, January 2010, http://nist.gov/public_affairs/releases/upload/smartgrid_interoperability_final.pdf [CTS2016] Cox, W. T., Cazalet, E., Krstulovic, A., Miller, W., & Wijbrandi, W. Common Transactive Services. TESC 2016. Available at http://coxsoftwarearchitects.com/Resources/TransactiveSystemsConf2016/Common%20Transactive%20 Services%20Paper%2020160516.pdf [EML-CTS] Energy Mashup Lab Common Transactive Services (open source software) https://github.com/EnergyMashupLab/eml-cts) [FSGIM] Facility smart grid information model. ISO 17800. https://www.iso.org/standard/71547.html 2017 [iCalendar] Internet Calendaring and Scheduling Core Object Specification (iCalendar), https://tools.ietf.org/html/rfc5545. 2009, B. Desruisseaux, See also Calendar Availability, https://tools.ietf.org/html/rfc7953, C. Daboo, M. Douglas. 2016 [SmartGridBusiness] Toby Considine and William Cox, Smart Loads and Smart Grids—Creating the Smart Grid Business Case. Grid-Interop 2009. Available at http://coxsoftwarearchitects.com/Resources/Grid- Interop2009/Smart%20Loads%20and%20Smart%20Grids.pdf [StructuredEnergy] Structured Energy: Microgrids and Autonomous Transactive Operation, http://coxsoftwarearchitects.com/Resources/ISGT_2013/ISGT-Cox_StructuredEnergyPaper518.pdf . Innovative Smart Grid Technologies 2013 (IEEE). [GridFaultResilience] William Cox and Toby Considine, Grid Fault Recovery and Resilience: Applying Structured Energy and Microgrids. IEEE Innovative Smart Grid Technologies 2014. Available at http://coxsoftwarearchitects.com/Resources/ISGT_2014/ISGT2014_GridFaultRecoveryResilienceStructur edMicrogrids_Paper.pdf [TRM] B. Huberman and S. H. Clearwater, Thermal markets for controlling building environments, Energy Engineering, vol. 91, no. 3, pp. 26- 56, January 1994. [UML] Object Management Group, Unified Modeling Language (UML), V2.4.1, August 2011. http://www.omg.org/spec/UML/2.4.1/

Note: OASIS strongly recommends that Technical Committees consider issues that might affect safety, security, privacy, and/or data protection in implementations of their work products and document these for implementers and adopters. For some purposes, you may find it required, e.g. if you apply for IANA registration. While it may not be immediately obvious how your work product might make systems vulnerable to attack, most work products, because they involve communications between systems, message formats, or system settings, open potential channels for exploit. For example, IETF [RFC3552] lists “eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle” as well as potential denial of service attacks as threats that must be considered and, if appropriate, addressed in IETF RFCs. In addition to considering and describing foreseeable risks, this section should include guidance on how implementers and adopters can protect against these risks. We encourage editors and TC members concerned with this subject to read Guidelines for Writing RFC Text on Security Considerations, IETF [RFC3552], for more information.

This work is derived from the specification EML-CTS, contributed by The Energy Mashup Lab, written by William T. Cox and Toby Considine.

C.1 Special Thanks Note: This is an optional subsection to call out contributions from TC members. If a TC wants to thank non-TC members then they should avoid using the term "contribution" and instead thank them for their "expertise" or "assistance". Substantial contributions to this document from the following individuals are gratefully acknowledged:

[Participant Name, Affiliation | Individual Member]

C.2 Participants The following individuals were members of this Technical Committee during the creation of this document and their contributions are gratefully acknowledged:

Rolf Bienert, OpenADR Alliance Toby Considine, University of North Carolina at Chapel Hill William T. Cox, Individual Member Pim van der Eijk, Sonnenglanz Consulting David Holmberg, National Institute for Standards & Technology (NIST) Elysa Jones, Individual Chuck Thomas, Electric Power Research Institute (EPRI)

Revision Date Editor Changes Made

WD01 2/15/2021 Toby Considine Initial reformatting and conversion of the specification contributed by The Energy Mashup Lab to create a document for committee work.

WD02 3/3/2021 Toby Considine Added prose definitions of Resource, Product, and Instrument

Copyright © OASIS Open 2021. All Rights Reserved. All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website: [https://www.oasis-open.org/policies-guidelines/ipr]. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OASIS AND ITS MEMBERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THIS DOCUMENT OR ANY PART THEREOF. As stated in the OASIS IPR Policy, the following three paragraphs in brackets apply to OASIS Standards Final Deliverable documents (Committee Specifications, OASIS Standards, or Approved Errata). [OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this deliverable.] [OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this OASIS Standards Final Deliverable. OASIS may include such claims on its website, but disclaims any obligation to do so.] [OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this OASIS Standards Final Deliverable or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Standards Final Deliverable, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.] The name "OASIS" is a trademark of OASIS, the owner and developer of this document, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, documents, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark for above guidance.